SOC 2 Guides/
Compensating Controls for Small Teams
SOC 2 Compliance Guide
SOC 2 Compensating Controls for Small Teams
When you're a one-person company or a team of two, traditional separation of duties doesn't work. Here's how to document compensating controls that auditors actually accept.
Why Compensating Controls Exist
SOC 2 doesn't require separation of duties. It requires that risks are adequately mitigated. Compensating controls are alternative measures that address the same risk when a primary control isn't feasible.
The AICPA's Trust Services Criteria (CC6.1) states that an entity should implement logical access security over information assets. For a 500-person company, this means different people write code, review code, and deploy code. For a solo operator or a team of three, that's impossible.
The solution isn't to pretend you have separation of duties. It's to formally document why you can't implement it and what you do instead.
Key Insight
Auditors don't fail you for being small. They fail you for not acknowledging the risk and not having documented alternatives. A well-documented compensating control is stronger than a poorly implemented separation of duties.
When Compensating Controls Apply
Solo founders who write, review, and deploy their own code
Teams of 2-3 where full role separation isn't practical
Small companies where one person handles both development and infrastructure
Bootstrapped startups pursuing SOC 2 before scaling the team
The Compensating Control Framework
Every compensating control document needs four components. Miss one and your auditor will send it back.
1 Risk Statement
What specific risk does the missing control create? Be precise. "No separation of duties" isn't a risk statement. "The same individual who writes code can deploy it to production without independent review" is.
2 Justification
Why can't you implement the standard control? Company size, resource constraints, and organizational structure are all valid reasons. Document them factually.
3 Compensating Control Description
What do you do instead? This must be specific, measurable, and verifiable. "We're careful" isn't a control. "All commits require passing CI checks including automated tests, linting, and security scanning before merge is permitted" is.
4 Monitoring & Evidence
How do you prove the control is operating? Auditors need evidence. Logs, screenshots, automated reports, and audit trails are your friends.
Common Mistake
Don't write compensating controls in vague, aspirational language. "We plan to review code regularly" won't pass. Write in present tense about controls that are already operating: "All production deployments are logged in the deployment tracker with timestamp, commit hash, and operator identity."
Template: Code Review Controls
When one person writes and merges code, automated tooling replaces a human reviewer.
Compensating Control: Code Review
COMPENSATING CONTROL DOCUMENT
Control Area: Code Review & Quality Assurance
Applicable TSC: CC8.1 (Change Management)
Effective Date: [DATE]
Owner: [NAME / TITLE]
─────────────────────────────────────────
1. RISK STATEMENT
Due to the company's size ([NUMBER] employees), the same
individual who authors code changes also has the ability to
approve and merge those changes into the production codebase.
This creates a risk that unauthorized, untested, or malicious
code could be introduced without independent review.
2. JUSTIFICATION
The organization currently operates with [NUMBER] technical
staff. Implementing traditional separation of duties for code
review would require hiring additional personnel, which is not
feasible given current organizational constraints. This
compensating control framework provides equivalent risk
mitigation.
3. COMPENSATING CONTROLS
a) Automated Code Quality Gates
- All code repositories enforce branch protection rules
- Direct commits to main/production branches are blocked
- All changes must pass through a pull request workflow
- CI pipeline runs automatically on every pull request:
* Unit tests (minimum [X]% code coverage enforced)
* Integration tests
* Static analysis (e.g., SonarQube, ESLint, Pylint)
* Dependency vulnerability scanning (e.g., Snyk, Dependabot)
* SAST scanning (e.g., Semgrep, CodeQL)
b) Time-Delayed Self-Review
- All pull requests must remain open for a minimum of
[4/8/24] hours before merge is permitted
- The author must re-review the diff after the waiting
period before merging
- The review is documented via a self-review comment
on the pull request
c) Automated Security Scanning
- Secret detection runs on every commit (e.g., GitLeaks)
- Container image scanning on build (e.g., Trivy)
- Infrastructure-as-code scanning (e.g., Checkov, tfsec)
d) Post-Merge Monitoring
- Production error rates are monitored after each deployment
- Automated rollback triggers if error rate exceeds
[X]% threshold within [Y] minutes of deployment
- All deployments are logged with commit hash, timestamp,
and deployer identity
4. EVIDENCE & MONITORING
| Evidence Type | Source | Frequency |
|------------------------|---------------------|------------|
| Branch protection log | GitHub/GitLab | Continuous |
| CI/CD pipeline results | CI platform | Per change |
| PR review comments | GitHub/GitLab | Per change |
| Security scan results | Scanning tools | Per change |
| Deployment logs | CI/CD pipeline | Per deploy |
| Error rate dashboards | Monitoring platform | Continuous |
5. REVIEW SCHEDULE
This compensating control is reviewed quarterly by [NAME]
to assess continued effectiveness and relevance. Review
dates: [Q1 DATE], [Q2 DATE], [Q3 DATE], [Q4 DATE]
Auditor Tip
The time-delayed self-review is one of the most effective compensating controls for solo operators. It simulates a second pair of eyes by forcing temporal separation between writing and reviewing. Many auditors specifically recommend this approach.
Template: Access Approval Controls
When the same person requests and grants access, automated logging and periodic reviews replace dual-approval workflows.
Compensating Control: Access Management
COMPENSATING CONTROL DOCUMENT
Control Area: Access Provisioning & Approval
Applicable TSC: CC6.1, CC6.2, CC6.3 (Logical Access)
Effective Date: [DATE]
Owner: [NAME / TITLE]
─────────────────────────────────────────
1. RISK STATEMENT
The organization's limited staffing means the individual
responsible for requesting access to production systems is
also the individual who provisions that access. This creates
a risk of excessive or unauthorized privilege escalation
without independent oversight.
2. JUSTIFICATION
With [NUMBER] employees, dedicating separate personnel to
access request and access approval functions is not
operationally feasible. The following compensating controls
ensure that access provisioning is transparent, logged, and
periodically reviewed.
3. COMPENSATING CONTROLS
a) Infrastructure-as-Code Access Management
- All access permissions are defined in version-controlled
IaC templates (Terraform, CloudFormation, or equivalent)
- Access changes require a code change that goes through
the standard PR workflow with automated checks
- No manual access provisioning via cloud console is
permitted outside of documented break-glass procedures
b) Principle of Least Privilege Enforcement
- All IAM roles and policies follow least-privilege design
- No standing admin access to production data stores
- Temporary elevated access via just-in-time (JIT) tooling
(e.g., AWS SSO with time-boxed sessions)
- Maximum session duration: [X] hours
c) Access Review Cadence
- Quarterly access reviews performed by [NAME]
- All active accounts, roles, and permissions are
enumerated and validated against business need
- Unused or excessive permissions are revoked
- Review results are documented and retained
d) Audit Logging
- CloudTrail / audit logs enabled on all cloud accounts
- All access provisioning events are logged with:
* Timestamp
* Identity of the provisioner
* Specific permissions granted
* Business justification (in commit message or ticket)
- Logs are stored in a tamper-evident, append-only store
with [90/365]-day retention
4. EVIDENCE & MONITORING
| Evidence Type | Source | Frequency |
|----------------------------|-------------------|------------|
| IaC change history | Git repository | Per change |
| Access review reports | Internal document | Quarterly |
| CloudTrail / audit logs | Cloud provider | Continuous |
| IAM policy snapshots | IaC state files | Per change |
| JIT access session logs | SSO provider | Per use |
5. REVIEW SCHEDULE
This compensating control is reviewed quarterly. Next
review: [DATE]. Access review reports are retained for
a minimum of [1 year / audit period + 1 year].
Template: Deployment Controls
When the developer is also the deployer, pipeline automation and approval gates replace human sign-off.
Compensating Control: Deployment Pipeline
COMPENSATING CONTROL DOCUMENT
Control Area: Production Deployment
Applicable TSC: CC8.1 (Change Management), CC7.1 (Monitoring)
Effective Date: [DATE]
Owner: [NAME / TITLE]
─────────────────────────────────────────
1. RISK STATEMENT
The same individual who develops code changes is also
responsible for deploying them to production. This creates
a risk that untested or unapproved changes could reach
production without adequate quality gates.
2. JUSTIFICATION
The organization has [NUMBER] technical staff. A separate
release management function is not feasible at current
scale. The following automated controls provide equivalent
assurance.
3. COMPENSATING CONTROLS
a) Automated Deployment Pipeline
- All production deployments occur through the CI/CD
pipeline only — no manual deployments permitted
- Pipeline enforces sequential gates:
1. Build and compile
2. Unit tests pass (100% required)
3. Integration tests pass
4. Security scans pass (zero critical/high findings)
5. Staging environment deployment & smoke tests
6. Production deployment
- Direct SSH/console access to production servers is
restricted to break-glass procedures only
b) Immutable Deployment Artifacts
- Build artifacts are created once and promoted through
environments (not rebuilt per environment)
- Artifacts are signed and checksummed
- Production can only deploy artifacts that passed all
prior gates
c) Automated Rollback
- Deployment health checks run for [X] minutes post-deploy
- Automatic rollback triggers if:
* Error rate exceeds [X]% above baseline
* Health check endpoint returns non-200
* P95 latency exceeds [X]ms threshold
- Manual rollback can be triggered at any time via
pipeline (reverts to last known good artifact)
d) Deployment Logging & Notification
- Every deployment is logged with:
* Commit SHA, branch, and PR reference
* Deployer identity
* Timestamp (start and end)
* Success/failure status
* Artifact checksum
- Deployment notifications sent to [Slack channel / email]
for visibility even when deployer is the sole operator
4. EVIDENCE & MONITORING
| Evidence Type | Source | Frequency |
|----------------------------|-------------------|------------|
| Pipeline execution logs | CI/CD platform | Per deploy |
| Gate pass/fail results | CI/CD platform | Per deploy |
| Deployment notifications | Slack / email | Per deploy |
| Rollback events | CI/CD platform | As needed |
| Artifact checksums | Artifact registry | Per build |
| Production health metrics | Monitoring tool | Continuous |
5. REVIEW SCHEDULE
This control is reviewed quarterly. Pipeline configuration
changes are tracked in version control and subject to the
same PR workflow as application code.
Implementation Note
The "no manual deployments" rule is critical. If your auditor discovers you SSH'd into production and ran a manual deploy, the entire compensating control framework for deployment is undermined. Use break-glass procedures with mandatory post-incident documentation for true emergencies.
Template: Change Management Controls
Tracking what changed, why, and when — even when one person owns the entire change lifecycle.
Compensating Control: Change Management
COMPENSATING CONTROL DOCUMENT
Control Area: Change Management & Tracking
Applicable TSC: CC8.1 (Change Management)
Effective Date: [DATE]
Owner: [NAME / TITLE]
─────────────────────────────────────────
1. RISK STATEMENT
Changes to production systems are initiated, approved, and
implemented by the same individual. This creates a risk of
unauthorized or undocumented changes being introduced without
adequate tracking or approval.
2. JUSTIFICATION
With [NUMBER] employees, a formal Change Advisory Board (CAB)
or multi-person approval chain is not feasible. The following
controls ensure all changes are documented, traceable, and
reversible.
3. COMPENSATING CONTROLS
a) Mandatory Change Documentation
- Every change requires a ticket/issue with:
* Description of the change
* Business justification
* Risk assessment (low/medium/high)
* Rollback plan
* Testing evidence
- Tickets are linked to pull requests and deployments
b) Change Classification & Approval Matrix
- Low-risk changes (config updates, copy changes):
Self-approved with documented justification
- Medium-risk changes (feature additions, dependency updates):
Self-approved with 24-hour waiting period and
documented risk assessment
- High-risk changes (infrastructure, security, data model):
External review required (advisor, contractor, or
automated security review)
c) Change Log
- An immutable, append-only change log is maintained
- Every production change is recorded with:
* Change ID (ticket reference)
* Date and time of implementation
* Description of change
* Implementer identity
* Verification steps performed
* Success/failure status
d) Post-Implementation Review
- All medium and high-risk changes undergo a documented
post-implementation review within [24/48] hours
- Review covers: Did the change achieve its objective?
Were there unexpected side effects? Is monitoring
confirming expected behavior?
4. EVIDENCE & MONITORING
| Evidence Type | Source | Frequency |
|----------------------------|-------------------|------------|
| Change tickets | Issue tracker | Per change |
| PR-to-ticket linkage | Git + tracker | Per change |
| Change log entries | Change log | Per change |
| Post-implementation reviews| Internal document | Per change |
| Quarterly summary report | Internal document | Quarterly |
5. REVIEW SCHEDULE
Change management process is reviewed quarterly. All change
records are retained for the audit period plus one year.
Building Your Evidence Package
Documentation without evidence is just a policy. Here's how to build an evidence package that satisfies auditors.
Automated Evidence Collection
The best evidence is evidence you don't have to remember to create. Set up these automated evidence sources:
Git commit history — Proves all changes went through version control
CI/CD pipeline logs — Proves automated tests and scans ran on every change
Cloud provider audit trail — Proves all infrastructure changes are logged
Deployment notification history — Proves deployments are tracked and timestamped
Monitoring dashboards — Proves production systems are observed post-deployment
Manual Evidence (Quarterly)
Some evidence needs to be generated on a schedule:
Access review report — Screenshot of all active users, roles, and permissions with confirmation each is still needed
Compensating control review — Signed statement that each compensating control was reviewed and remains effective
Change log summary — High-level summary of all production changes for the quarter
Incident log review — Confirmation that any incidents were handled per documented procedures
Evidence Retention
Retain all evidence for the entire audit period plus at least one year. SOC 2 Type II audits typically cover 6-12 months. Your auditor will sample evidence from across this period — not just the most recent month.
Control Mapping Matrix
Map your compensating controls back to the Trust Services Criteria. This table shows your auditor that every risk area is covered.
Automated health checks + auto-rollback + deployment logging
Low
CC7.2
Separate monitoring and operations
Automated alerting + third-party monitoring tools
Low
What Auditors Look For
After working through dozens of SOC 2 audits for small teams, these are the patterns that succeed and the ones that don't.
What Works
Specificity over length. A two-page compensating control document with specific tool names, thresholds, and frequencies beats a twenty-page policy full of "should" and "may."
Automation over process. "Branch protection prevents direct pushes to main" is stronger than "employees are trained not to push directly to main."
Continuous evidence over point-in-time snapshots. Audit logs that run 24/7 are more convincing than quarterly screenshots.
Honest risk acknowledgment. Stating "this is a residual risk we accept" for low-impact items shows maturity, not weakness.
What Fails
Copy-pasted enterprise policies. If your policy references a "Security Review Board" that doesn't exist, you'll get findings.
Future-tense controls. "We will implement automated scanning" is not a control. It's a wish.
Missing evidence. If you claim quarterly access reviews but can't produce the review artifacts, the control fails.
Ignoring the gap. Not mentioning separation of duties at all is worse than documenting a compensating control for it.
Red Flag
If your compensating control document reads like it was written for a Fortune 500 company, your auditor will know it was templated without thought. Tailor every document to your actual team size, tools, and processes. Authenticity matters.
Implementation Checklist
Use this checklist to ensure your compensating controls framework is complete before your audit engagement begins.
Code Review Controls
Branch protection rules enabled on all production repositories
CI pipeline configured with tests, linting, and security scanning
Time-delayed self-review policy documented and enforced
Pull request template includes self-review checklist
Access Management Controls
All access permissions defined in version-controlled IaC
Quarterly access review schedule established
JIT access tooling configured for elevated privileges
Cloud audit logging enabled and retained for required period