ITGC Readiness (SOC / SAS 70)

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)?
Medium

This control requires that all requests to provision user access to systems, applications, or data repositories are approved by two parties—the user's manager (to confirm business need) and the system owner or data custodian (to authorize access appropriate to the…

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?
Medium

This control ensures that user access rights to systems, applications, and data are revoked within 24 hours of employment termination or role transfer. It requires documented evidence of the deprovisioning action, including timestamps and authorizing personnel. Timely access removal prevents…

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?
Medium

This control requires organizations to conduct formal reviews of user access rights for all in-scope systems on a quarterly basis (at minimum every 90 days). Access reviews involve examining current user accounts, permissions, and privilege assignments against business justifications, verifying…

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?
Medium

This control requires organizations to limit the number of privileged accounts, assign unique individual identifiers to each privileged user (no shared credentials), continuously monitor privileged account activity through logging and alerting mechanisms, and conduct formal access reviews at least 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?
Medium

This control ensures all production changes follow a structured change management process requiring formal documentation, technical peer review, managerial approval, and full traceability between approved change tickets and deployed code or configuration artifacts. Each production deployment must be linked to…

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)?
Medium

This control ensures that development, testing, and production environments are logically and physically isolated to prevent unauthorized changes to live systems. Developers are restricted from directly deploying code to production without formal approval and release management processes. Segregation of duties…

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)?
Medium

Emergency changes, often implemented outside standard approval workflows to restore service or remediate critical security incidents, must still be subject to governance through post-implementation review and retroactive approval processes. Organizations must document the justification, actions taken, and approvers who validate…

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?
Medium

This control ensures that automated batch jobs, ETL processes, scheduled tasks, and data pipelines are continuously monitored for successful execution, and that failures, delays, or anomalies trigger alerts to operations or engineering teams. Implementation typically involves job schedulers (e.g., cron,…

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)?
Medium

This control ensures that critical business systems and data are backed up on a defined schedule, that backup media and storage locations are protected against unauthorized access and environmental hazards, and that restore procedures are validated through at least one…

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?
Medium

This control ensures that all security-relevant logs (authentication events, access control decisions, system changes, security tool alerts, and application security events) are forwarded to a centralized logging platform, retained for a minimum of 12 months to support incident investigation and…

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?
Medium

This control requires the organization to maintain a documented incident response process that includes defined roles, communication procedures, detection and analysis workflows, containment strategies, eradication steps, recovery procedures, and post-incident review activities. The process must be formally exercised through tabletop…

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?
Medium

This control ensures that the organization actively reviews the security posture and operational practices of third-party service providers, particularly cloud infrastructure providers, SaaS vendors, and data processors that handle or process organizational data. Organizations must obtain and evaluate independent audit…

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)