About this program
Whether you call it SAS 70, SSAE 18, SOC 1 or SOC 2, the IT general controls auditors test are the same: access management, change management, computer operations, and information security. After each answer you can expand an “Auditor’s view” showing how the control is tested, what evidence to collect, and the ideal response.
Controls (12)
-
Is user provisioning approved (manager + system owner) and recorded with evidence (ticket, signature)?
MediumIs user provisioning approved (manager + system owner) and recorded with evidence (ticket, signature)?
How to test + evidence
Risk: Automated workflows produce a tamper-evident audit trail and enforce dual approval in code, making the control testable and consistently applied.
Testing procedure: Walkthrough the joiner workflow with HR and IT. Then pick a sample of new hires from the HR list (typically 25 from the audit period) and trace each one to a provisioning ticket, the approval, and the actual access granted.
Evidence to collect: List of joiners during the audit period (HR system export) Provisioning tickets with manager + system owner approvals System access reports showing the user was created with the approved roles Screenshot of the access request form / workflow tool
-
Is access removed for terminated/transferred users within 24 hours, with evidence?
MediumIs access removed for terminated/transferred users within 24 hours, with evidence?
How to test + evidence
Risk: Automation linked to the HR system reduces the window during which a leaver retains access — the most common audit finding in this area.
Testing procedure: From the HR leavers list, sample 25 terminated users. For each, get the termination date and compare to the date access was disabled in the IDP, key applications, and any standalone systems (DB admin, hypervisors, network gear).
Evidence to collect: HR leaver list with termination dates IDP user disabled-on timestamps (Entra/Okta/Google audit log) Application user list export showing inactive status Tickets confirming offboarding completion
-
Are user access reviews performed at least quarterly for in-scope systems, with evidence of approval and remediation?
MediumAre user access reviews performed at least quarterly for in-scope systems, with evidence of approval and remediation?
How to test + evidence
Risk: Quarterly cadence catches drift faster, and tooling makes the review tractable for systems with many users — annual reviews tend to find too much to action meaningfully.
Testing procedure: Request the most recent access review for each in-scope system. Verify it covers the full user population, was performed by the system owner (not IT), and that any flagged accounts were remediated within a defined SLA.
Evidence to collect: Access review reports with reviewer signatures and dates List of accounts flagged for change/removal Tickets evidencing the remediation actions Screenshots showing the changes applied in the system
-
Are privileged accounts limited, monitored, with separate IDs and reviewed monthly?
MediumAre privileged accounts limited, monitored, with separate IDs and reviewed monthly?
How to test + evidence
Risk: Privileged access is the most-attacked control and most likely to fail an audit. JIT + session recording transforms standing privilege into time-bounded, auditable activity.
Testing procedure: List all admin / root / sudoer accounts across in-scope systems. Verify each has a named human owner (no shared accounts), is separate from the user's daily account, has an approved business justification, and has been reviewed within the last month.
Evidence to collect: List of privileged accounts per system with owner mapping Most recent monthly privileged access review PAM session logs / recordings (if applicable) Just-in-time elevation logs showing time-bounded grants
-
Are production changes documented in a ticket, peer-reviewed, approved and traceable to the deployed artefact?
MediumAre production changes documented in a ticket, peer-reviewed, approved and traceable to the deployed artefact?
How to test + evidence
Risk: IaC + PR review enforces the control in tooling rather than relying on people remembering to file a ticket — the audit trail is automatic.
Testing procedure: Pull a sample of 25 production changes from the last 12 months. For each, expect: a ticket with business justification, evidence of testing, peer review (PR or CAB), approval before deployment, and a deployment record matching the ticket.
Evidence to collect: Sample of change tickets (Jira / ServiceNow) PR records with reviewer + merge timestamps CI/CD deployment logs tying to the ticket Change Advisory Board minutes if applicable
-
Are dev / test / production environments properly segregated and is segregation of duties enforced (developers can't deploy to production without approval)?
MediumAre dev / test / production environments properly segregated and is segregation of duties enforced (developers can't deploy to production without approval)?
How to test + evidence
Risk: Enforced SoD removes the audit risk of relying on goodwill — auditors specifically look for cases where one person can both code and deploy unilaterally.
Testing procedure: Map who has access to deploy to production vs who writes code. Inspect the CI/CD permissions and confirm a developer cannot push code that auto-deploys to prod without approval from a separate person (or role).
Evidence to collect: List of users with production deploy permissions CI/CD pipeline configuration showing approval gates Sample of recent deployments showing dev + approver are different people IaC repository CODEOWNERS / branch protection rules
-
Are emergency changes governed (post-implementation review, retroactive approval, documented)?
MediumAre emergency changes governed (post-implementation review, retroactive approval, documented)?
How to test + evidence
Risk: Emergency change abuse is a classic audit finding — every emergency that lacks a PIR opens up the question of whether the standard change process is being bypassed.
Testing procedure: Identify all changes flagged as "emergency" or "expedite" during the audit period. For each, verify a post-implementation review was completed within the SLA (typically 5 business days) with retroactive approval recorded.
Evidence to collect: List of emergency changes with timestamps Post-implementation review documents Retroactive approval records Ratio of emergency to standard changes (auditors look for spikes)
-
Are scheduled batch jobs / data pipelines monitored, with failures alerted to ops?
MediumAre scheduled batch jobs / data pipelines monitored, with failures alerted to ops?
How to test + evidence
Risk: Observability + on-call closes the loop: detection without response is a control gap. Auditors specifically test that someone gets paged when a critical job fails at 3am.
Testing procedure: Identify the critical scheduled jobs (financial close, billing, data pipelines). Check that monitoring is in place, alerts have a named on-call recipient, and incidents from the last 12 months were investigated and resolved.
Evidence to collect: List of in-scope batch jobs with schedule + owner Monitoring dashboard screenshot or config export Sample of failed jobs from the audit period with resolution notes On-call schedule / rotation document
-
Are backups taken, secured, and tested (at least one full restore in the last 12 months)?
MediumAre backups taken, secured, and tested (at least one full restore in the last 12 months)?
How to test + evidence
Risk: A backup that has never been restored is an article of faith, not a control. Quarterly restore tests catch backup tooling regressions before a real incident does.
Testing procedure: Inspect the backup configuration for in-scope systems. Confirm backups complete daily, are stored off-site or in a separate account, and that at least one restore test in the audit period proved the backups can actually be recovered.
Evidence to collect: Backup job logs showing daily success Restore test report with date, scope, and outcome Backup retention policy document Configuration showing immutability / object-lock for cloud backups
-
Are security-relevant logs centralised, retained for at least 12 months, and reviewed?
MediumAre security-relevant logs centralised, retained for at least 12 months, and reviewed?
How to test + evidence
Risk: Auditors look for both technical retention and an independent reviewer — without separation, the same person who can change a system also controls the only record of having done so.
Testing procedure: Verify that authentication, privileged action, and configuration-change logs from in-scope systems are centralised. Confirm retention covers the full audit period (12 months minimum) and that logs are reviewed by someone other than the system administrator.
Evidence to collect: SIEM coverage matrix (which systems forward which logs) Retention policy + actual log retention shown in tooling Sample alerts triaged with timestamps Independence: review performed by a role outside system admin
-
Is there a documented incident response process exercised at least annually?
MediumIs there a documented incident response process exercised at least annually?
How to test + evidence
Risk: A plan that has never been tested falls apart on contact with reality. Annual tabletops surface gaps in roles, escalation, and out-of-band communications before a real incident does.
Testing procedure: Request the IR plan and the most recent tabletop / exercise after-action report. For real incidents during the audit period, sample 3 and trace through the playbook: detection → triage → containment → eradication → recovery → lessons learned.
Evidence to collect: Incident response plan with version and approver Most recent tabletop after-action report Real incident records with timeline + decisions Lessons-learned tracker showing actions completed
-
Are sub-service organisations (cloud providers, processors) reviewed (SOC reports / audits) and risks documented?
MediumAre sub-service organisations (cloud providers, processors) reviewed (SOC reports / audits) and risks documented?
How to test + evidence
Risk: Sub-service organisations are an explicit audit consideration. Without their SOC reports + CUEC mapping, your own opinion is exposed to whatever they aren't doing — and the auditor cannot rely on it.
Testing procedure: List in-scope sub-service organisations (e.g. AWS, Azure, payroll provider). Verify a current SOC 1 / SOC 2 report has been obtained for each and that the Complementary User Entity Controls (CUECs) have been mapped to your own controls.
Evidence to collect: Vendor register with criticality + scope SOC 1 / SOC 2 reports (current within 12 months) CUEC mapping document — what you must do based on the sub-service report Annual review evidence (date + reviewer + outcome)