Common SOC 2 controls

SOC 2 is not a checklist that says “install these 47 tools.” It is a framework that you fill in yourself. This page shows the most common controls, what they mean, and how to implement them in practice. The AICPA Trust Services Criteria  describe the requirements, and this page translates them into concrete measures.

Think of these controls as building blocks. You choose what is relevant for your organisation, link them to the right Trust Services Criteria, implement them, and prove that they work.

SOC 2 security controls (mandatory for everyone)

1. Multi-factor authentication (MFA)

What: Access to critical systems requires a second factor in addition to the password.

Implementation:

• AWS/Azure/GCP: MFA required for console access
• GitHub/GitLab: MFA required at organisation level
• Google Workspace/Office 365: MFA for all users
• Application admin accounts: MFA required
• SSH/server access: key-based, with optional TOTP

Tools:

• Google Authenticator (free)
• 1Password/LastPass MFA (€5/user/month)
• YubiKey hardware tokens (€45 one-time)
• Duo Security (€3/user/month)

Evidence:

• Screenshots of MFA settings (monthly)
• Audit logs of MFA-protected logins
• Policy document stating the MFA requirement

Common mistake: MFA is “available” but not “enforced.” The auditor checks whether users can switch it off. They must not be able to.

2. Role-based access control (RBAC)

What: Users get access based on their role, not ad hoc. Principle of least privilege.

Implementation:

• Defined roles: Admin, Developer, Support, ReadOnly
• Access matrix: which role has access to which system
• No shared accounts (no “admin@company.com”)
• Quarterly access reviews: check whether people still have the right access

Tools:

• AWS IAM roles and policies
• GitHub teams and permissions
• Google Workspace groups
• Okta/Auth0 for app-level RBAC

Evidence:

• Access control matrix (Excel showing who may do what)
• AWS IAM policy documents
• Screenshots of role assignments
• Quarterly access review meeting minutes

Example matrix:

3. Onboarding and offboarding procedures

What: New employees get the right access within X days. Leavers lose access within 24 hours.

Implementation: Onboarding:

• HR form triggers an IT ticket
• Background check completed before access is granted
• NDA signed
• Security awareness training within 7 days
• Access provisioned according to role
• Welcome email with policies

Offboarding:

• HR notifies IT of the last working day
• All accounts disabled within 24 hours
• Hardware returned (laptop, badges)
• Exit interview (optional but recommended)

Tools:

• HRIS: BambooHR, Workday
• Ticketing: Jira Service Desk, Zendesk
• MDM: Jamf, Kandji (remote wipe capability)
• IAM: Okta (automated deprovisioning)

Evidence:

• Sample of 5-10 onboardings: HR form, IT ticket, training completion, access grant email
• Sample of 5-10 offboardings: termination notice, account disabled logs, hardware return receipt
• Policy document with timelines

Common mistake: Getting a laptop back takes three weeks for a remote employee. That is fine, but the account must be disabled within 24 hours. Hardware is a separate concern.

4. Logging and monitoring

What: All important events are logged. Logs are centralised and monitored for suspicious activity.

Implementation:

• Centralised logging (SIEM): all logs in one place
• Log retention: at least 90 days, often one year
• Monitoring of authentication events, access changes, errors and security events
• Alerting for critical events (failed logins, privilege escalation, data export)
• Weekly log review (automated plus manual spot checks)

Tools:

• SIEM: Splunk, Datadog, ELK Stack, Sumo Logic
• Cloud-native: AWS CloudWatch, Azure Monitor, GCP Logging
• Security-focused: Panther, Lacework

Evidence:

• SIEM dashboard screenshots
• Log retention policy document
• Sample alerts and investigation notes
• Weekly log review reports

What to log:

• Authentication: who logs in, when, from where, success or failure
• Authorisation: access grants, role changes, permission elevations
• Data access: database queries, file downloads, API calls
• Changes: code deploys, infrastructure changes, configuration updates
• Security events: firewall blocks, IDS alerts, malware detection

5. Encryption

What: Data is encrypted at rest (on disk) and in transit (over the network).

Implementation: At rest:

• Database encryption (RDS, MongoDB Atlas, etc.)
• S3 bucket encryption (default encryption enabled)
• Laptop full-disk encryption (FileVault, BitLocker)
• Backup encryption

In transit:

• TLS 1.2+ for all external connections
• No legacy protocols (SSL 3.0, TLS 1.0/1.1)
• Internal traffic encrypted where possible (service mesh, VPN)
• Email encryption (opportunistic TLS)

Tools:

• Cloud provider native encryption (AWS KMS, Azure Key Vault)
• Certificate management: Let’s Encrypt, AWS Certificate Manager
• Laptop: FileVault (Mac), BitLocker (Windows)

Evidence:

• Screenshots of encryption settings
• Certificate validity checks
• Encryption key rotation logs
• SSL Labs scan results (A rating minimum)

Common mistake: Encryption is switched on, but the keys are not managed. “Who has access to the encryption keys?” is an auditor question. The answer must be: only authorised personnel, documented in policy.

6. Vulnerability and patch management

What: Systems are scanned for vulnerabilities on a regular basis. Critical and high vulnerabilities are patched quickly.

Implementation:

• Weekly automated vulnerability scans
• Dependency scanning for code (npm audit, Snyk, Dependabot)
• OS patch management (automated updates where possible)
• SLAs: critical 7 days, high 30 days, medium 90 days
• Exception process: if a patch is not possible, document the risk acceptance

Tools:

• Vulnerability scanning: Tenable Nessus, Qualys, Rapid7
• Dependency scanning: Snyk, GitHub Dependabot, WhiteSource
• Patch management: AWS Systems Manager, WSUS, Ansible

Evidence:

• Weekly scan reports (6 months)
• Patch deployment logs
• Risk acceptance documents (for vulnerabilities that have not been patched)
• Metrics: average time to patch, percentage compliant with SLA

Common mistake: Scans run and vulnerabilities are found, but nobody follows up. The auditor sees a critical vulnerability that is 90 days old and asks, “Why has it not been patched?” Without a good answer, that is a finding.

7. Incident response

What: You have a plan for security incidents. You know what to do, who to call and how to communicate.

Implementation:

• Incident Response Plan document
• Defined roles: Incident Commander, Communications Lead, Technical Lead
• Escalation procedures
• Communication templates (internal, customer, press)
• Annual testing (tabletop exercise)
• Incident log (all incidents documented)

Tools:

• Incident management: PagerDuty, Opsgenie, VictorOps
• Communication: Slack incident channels, status page
• Forensics: packet captures, log analysis tools

Evidence:

• Incident Response Plan document
• Tabletop exercise meeting notes
• Incident log (real incidents, if any, with postmortems)
• Training records (who was trained on the IRP)

What to log per incident:

• Date and time detected
• Description
• Severity
• Assigned to
• Actions taken
• Resolution
• Root cause
• Preventive measures

8. Change management

What: Production changes follow a documented process. No cowboy deploys.

Implementation:

• All changes go through a ticketing system (Jira, GitHub Issues)
• Peer review required (code review, infrastructure review)
• Approval workflow (depends on the size of the change)
• Testing procedures
• Deployment window (maintenance windows for risky changes)
• Rollback plan
• Post-deploy monitoring

Tools:

• Ticketing: Jira, Linear, Asana
• Code review: GitHub, GitLab, Bitbucket
• CI/CD: GitHub Actions, GitLab CI, CircleCI, Jenkins
• Deployment tracking: changelog, release notes

Evidence:

• Sample of 15-20 changes: ticket, approval, review, test results, deploy logs
• Change management policy
• Emergency change procedure (for hotfixes)
• Failed change and rollback evidence (shows the process works)

Common mistake: The process exists, but emergency changes bypass it without documentation. “Hotfix deployed at 3am without approval.” Fine, but where is the emergency change policy? If there is none, that is a finding.

9. Vendor risk management

What: Third-party vendors are assessed for security before you hire them. Existing vendors are reviewed regularly.

Implementation:

• Vendor register: a list of all vendors that have data or system access
• Due diligence: request a SOC 2 report, ISO 27001 certificate or security questionnaire
• Contract reviews: security clauses, DPAs (Data Processing Agreements)
• Annual vendor reviews: is the SOC 2 report up to date? Any breaches? Still compliant?
• Sub-processor notifications (GDPR requirement)

Tools:

• Vendor management: Vendr, Vanta, Drata (automated vendor tracking)
• Contract management: DocuSign CLM, Ironclide
• Security questionnaires: StandardizedSecurityQuestionnaires.com

Evidence:

• Vendor register (Excel: vendor name, service, data access, SOC 2 status, review date)
• Vendor SOC 2 reports (for critical vendors)
• DPAs
• Annual review meeting notes

Critical vs non-critical vendors: Critical (must have SOC 2 or ISO 27001):

• Cloud provider (AWS, Azure, GCP)
• Database hosting
• Email provider
• Authentication provider

Non-critical (a security questionnaire is enough):

• Marketing tools
• Analytics
• Non-production tools

10. Security awareness training

What: All employees receive security training. At least annually, preferably more often.

Implementation:

• New hire training (within 7-14 days)
• Annual refresher for all employees
• Topics: phishing, password security, data handling, incident reporting
• Phishing simulations (quarterly)
• Metrics tracked: completion rate, phishing simulation click rate

Tools:

• Training platforms: KnowBe4, Infosec IQ, Habitu8
• Phishing simulation: KnowBe4, PhishMe
• DIY: internal presentations and a quiz

Evidence:

• Training completion records (name, date, passed quiz)
• Phishing simulation results
• Training materials (slides, videos)
• Policy: annual training requirement

Common mistake: Training is “available” but not “required.” The completion rate is 60%. The auditor asks why 40% did not complete it. Without enforcement, that is a finding.

SOC 2 availability controls (optional, but often chosen)

11. Backup and disaster recovery

What: Critical data is backed up on a regular basis. Backups are tested with restore tests. You have a plan for disaster scenarios.

Implementation: Backups:

• Automated daily backups
• Backups stored off-site (a different geographic region)
• Backup encryption
• Quarterly restore tests (pick a random backup, restore it, verify it)
• Retention: 30 days of daily backups, 12 months of weekly backups

Disaster recovery:

• DR plan document: what to do if the data centre burns down
• RTO (Recovery Time Objective): how long until you are back online?
• RPO (Recovery Point Objective): how much data loss is acceptable?
• Annual DR test (simulated disaster, execute the recovery)

Tools:

• Cloud-native: AWS Backup, Azure Backup
• Database-specific: RDS automated backups, MongoDB Atlas backups
• Application: Velero (Kubernetes), Restic

Evidence:

• Backup schedules configured (screenshots)
• Quarterly restore test reports
• DR plan document
• Annual DR test meeting notes and results

Common mistake: Backups run, but the restore is never tested. The auditor asks, “Show me the last restore test.” You have not done one. That is a finding. Untested backups are no backups.

12. Capacity planning and monitoring

What: You monitor resource usage. You plan for growth. You have alerting for capacity issues.

Implementation:

• Resource monitoring: CPU, memory, disk, network
• Threshold alerting: 80% disk is a warning, 90% is critical
• Quarterly capacity reviews: trend analysis and forecasting
• Load testing before major events
• Scaling procedures (manual or auto-scaling)

Tools:

• Monitoring: Datadog, New Relic, Prometheus and Grafana
• Cloud-native: AWS CloudWatch, Azure Monitor
• Load testing: k6, Gatling, JMeter

Evidence:

• Monitoring dashboards
• Capacity review meeting notes
• Load test results
• Alerting configuration
• Scaling events (auto-scaling triggered)

13. SLA monitoring and reporting

What: If you have an SLA (99.9% uptime), you must prove that you meet it.

Implementation:

• Uptime monitoring (external, not just internal)
• SLA reporting (monthly): actual uptime compared with promised uptime
• Downtime tracking: incidents, duration, root cause
• Status page (public or private) for transparency

Tools:

• Uptime monitoring: Pingdom, UptimeRobot, StatusCake
• Status pages: StatusPage.io, Atlassian Statuspage
• APM: Datadog, New Relic (tracks latency, errors, Apdex)

Evidence:

• Monthly SLA reports
• Downtime incident reports
• Uptime monitoring graphs (6 months)
• Customer communications during downtime

Common mistake: A 99.9% SLA allows about 43 minutes of downtime per month. You had 120 minutes of downtime in one month. That breaches the SLA, and the auditor will see it. Whether it is a finding depends. If it was a one-off, documented and the customer was compensated, it may be acceptable. If it is a pattern, it is a finding.

SOC 2 confidentiality controls (optional)

14. Data classification

What: Data is classified (Public, Internal, Confidential, Restricted). How you handle it depends on the classification.

Implementation:

• Data classification policy: defines the levels
• Tagging and labelling of data
• Access controls based on classification
• Handling procedures per level (for example, Confidential must be encrypted)

Tools:

• DLP (Data Loss Prevention): Symantec DLP, Microsoft Purview
• Cloud-native: AWS Macie (scans S3 for sensitive data)
• Manual: tags in databases, file naming conventions

Evidence:

• Data classification policy
• Examples of classified data
• Access controls aligned with classification
• Audit logs of access to Confidential data

Classification example:

• Public: website content, blog posts, public documentation
• Internal: internal wikis, non-sensitive company information
• Confidential: customer data, contracts, financial data
• Restricted: PII, PHI, trade secrets, legal documents

15. Data loss prevention (DLP)

What: Prevent confidential data from being shared by accident (email, download, upload).

Implementation:

• DLP rules in email (no emailing confidential files to external recipients)
• DLP for file uploads (no uploading to a personal Dropbox)
• USB port control (disable or monitor)
• Data exfiltration monitoring (large downloads, unusual exports)

Tools:

• Email DLP: Google Workspace DLP, Microsoft 365 DLP
• Endpoint DLP: Symantec, McAfee, Carbon Black
• Network DLP: Forcepoint, Netskope

Evidence:

• DLP policy configuration
• Alerts triggered and investigation
• Training: employees aware of DLP rules
• Exceptions (if any): documented and approved

Common mistake: DLP is configured, but the alerts are ignored. The auditor sees 50 alerts in six months and asks, “What did you do with these?” No follow-up is a finding.

SOC 2 privacy controls (optional)

16. Privacy policy and consent management

What: You have a privacy policy. Users are informed. Consent is obtained.

Implementation:

• Privacy policy: readable, accessible, GDPR and CCPA compliant
• Cookie consent banner (strict mode: no tracking without consent)
• Consent records: log who approved what, and when
• Opt-out mechanisms: easy to withdraw consent

Tools:

• Cookie consent: OneTrust, Cookiebot, Osano
• Privacy management: OneTrust, TrustArc, Securiti

Evidence:

• Privacy policy document
• Consent banner screenshots
• Consent logs
• User complaints and requests handled

17. Data subject rights (DSR)

What: Users can view, export, correct and delete their data.

Implementation:

• DSR request process: how users submit requests
• Response SLA: within 30 days (GDPR requirement)
• Data export tool (users can download their data)
• Deletion procedures: hard delete, not soft delete
• Verification: confirm identity before granting a request

Tools:

• Privacy request management: OneTrust, TrustArc
• Data export: custom build (API endpoint)
• Deletion: automated scripts or a manual process

Evidence:

• Sample DSR requests and responses
• DSR policy document
• Timelines showing requests handled within the SLA
• Deletion logs (proof of deletion)

Types of DSR:

• Access: “Give me a copy of my data”
• Portability: “Export my data in a machine-readable format”
• Rectification: “Correct my data, it is wrong”
• Erasure: “Delete my data” (right to be forgotten)
• Objection: “Stop processing my data for X purpose”
• Restriction: “Temporarily pause processing”

More information

• Trust Services Criteria: the 5 pillars explained
• Step-by-step plan: the 12 steps to SOC 2
• The audit process: what the auditor tests
• Collecting evidence: what auditors want to see per criterion and how to organise it
• For SaaS companies: specific tips for SaaS
• AICPA TSC : official criteria