For a small team running a SaaS product, useful evidence often already lives in access records and deployment tools. Start there. Do not create a separate spreadsheet just to copy the same information.
The examples below fit a cloud-hosted application. They show possible control wording and what could demonstrate it. Adapt them to your actual process; four examples are not a complete SOC 2 program.
1. Limit temporary production access
Example control wording: The service owner approves temporary production access for a stated task. Access expires at the approved end time. The team checks and records any extension.
- Evidence to keep: The approved request and the access-system record showing permissions and expiration. Retain any extension approval.
- Check: A ticket marked closed does not prove access ended. Check the actual account or role.
If your tool does not support automatic expiry, define who removes access and how they confirm it. Do not describe an automatic control that is really manual.
2. Review a routine deployment
Example control wording: A reviewer other than the author checks a routine production change before release. Required tests pass before the deployment process proceeds.
- Evidence to keep: Link the reviewed code change to its test results and deployment record.
- Check: Confirm the released version matches the reviewed version. A successful deployment alone does not establish review.
This example assumes a capable second reviewer. For a smaller team, assess other ways to address conflicting duties. Use a separately defined process for urgent changes rather than quietly bypassing the routine one.
3. Check separation between customers
Example control wording: Changes affecting customer-data access include tests confirming that one customer’s account cannot retrieve another customer’s records through the changed functions.
- Evidence to keep: The test cases and results linked to the change. Keep the correction and retest if a check fails.
- Check: Use controlled test accounts and fictional records. Cover relevant application requests, not just whether a screen hides a button.
These checks address a specific access risk. They do not replace a broader security test or prove that every part of the application is isolated.
4. Check that a recovery works
Example control wording: The service team performs recovery tests under its approved schedule. It checks that restored data supports the selected business tasks and records gaps against the recovery objectives.
- Evidence to keep: The test plan and backup used. Record the task results and elapsed time. Link problems to their fixes and retests.
- Check: State the limits of the exercise. Restoring one database does not prove the entire service can recover.
Choose the scope and schedule from the service’s risks and commitments. Do not inherit a deadline from a generic template.
What the cloud provider does not prove for you
The provider may operate the physical facility and parts of the platform. Your responsibilities depend on the services you choose. A managed database and a virtual machine do not leave you with the same work.
The provider’s SOC report does not establish that your application blocks cross-customer access or that your staff approved a deployment. Review the provider’s coverage and keep evidence for the controls your team operates.
Keep the record simple
For each control, identify the owner and where the evidence lives. Use links to existing records. Protect those records and retain them under your agreed requirements.
Sources
- AICPA Trust Services Criteria: access controls under CC6, changes under CC8.1 and recovery testing under A1.3 when Availability is included. These examples are not mandatory AICPA wording.
- AWS shared responsibility model: responsibilities vary with the cloud services used. Check the equivalent documentation for your provider.
One Response