SOC 2 with a small team: segregation of duties and oversight

How a small team meets SOC 2 segregation of duties

SOC 2 does not require a large company, but a small team has to show that the common criteria on control environment, communication, control activities and logical access are designed and operating, including CC1.2, CC1.3, CC5.1 and CC6.3. These criteria assume that people who approve changes, grant access and review results are not the same people who perform the work. The organization owns its controls. An implementation partner such as DeployOpen can prepare systems, procedures and evidence, but only the independent CPA firm examines the controls and issues the report. Before the examination starts, ask the CPA firm in writing whether a minimum set of common controls and any compensating controls will be accepted for your size, because the AICPA staff FAQs published in December 2020 address both questions.

Start with a role map. List every production access path, deployment permission, code merge right, and administrative right in your cloud accounts and source control, then record who holds each one. Where one engineer can write code, approve it, and deploy it, that is the gap the auditor will test first. CC6.3 asks you to grant, change and remove access based on roles and to take least privilege and segregation of duties into account, so the role map should show how each permission is limited, reviewed and removed when someone leaves. Confirm with your auditor which combinations they treat as incompatible before you finalize it.

Where full separation is not possible, a compensating control replaces it. Examples include a second reviewer on every production change through required pull request approvals, logged break-glass access with a named approver, and a periodic review by a founder or outside advisor who did not perform the work. Each compensating control needs an owner, a defined frequency and a record that shows it ran. Board oversight is handled the same way. CC1.2 expects a board that is independent of management, and a small company without that board should document how an independent party reviews internal control, then confirm with the CPA firm how the AICPA staff FAQs apply to its design opinion.

What the criteria assume about separate roles

SOC 2 criteria are written for organizations where the people who approve, build, operate and review systems are different people. A small engineering team can still meet them, but it has to show which person holds each role and how the auditor can test that the roles are kept apart. The cards below cover the four places where the criteria most often assume separation.

Board independence under CC1.2

CC1.2 restates COSO Principle 2, which expects a board independent of management to oversee internal control. A founder-led company with no independent board can still be assessed, but the auditor will look for another body that reviews control decisions. AICPA staff FAQs from December 2020 address how a lack of an independent board affects the opinion on suitability of design. Ask your auditor early how they will treat this, and document who reviews controls and how often.

Reporting lines and authorities

CC1.3 asks the organization to establish reporting lines and to define, assign and limit authorities and responsibilities. In a small team, this usually means a short written chart showing who approves production access, who signs off policy changes and who can override a control. Limits matter as much as grants: a CTO who can approve their own deployments has an authority the auditor will question. Keep the chart current and dated so it can be sampled.

Segregation of duties under CC5.1

CC5.1 lists segregation of duties as one point of focus for choosing control activities. Points of focus are characteristics that help design and evaluate controls, not separate requirements, and not every one must be addressed. For a small team, the practical question is whether the same person can write code, approve it and deploy it. Where they can, a documented second reviewer, a protected branch rule or a compensating review may be the control the auditor tests.

Least privilege and role-based access under CC6.3

CC6.3 requires access to data, software, functions and other protected assets to be granted, changed or removed based on roles, responsibilities or system design, with least privilege and segregation of duties taken into account. Small teams often hold broad administrator rights for convenience. Define a short role list, map each engineer to roles, and remove standing production access where possible. The auditor will sample joiner, mover and leaver records against those roles, so the mapping must match what the systems actually allow.

What board oversight looks like without an independent board

CC1.2 expects the board of directors to be independent of management and to oversee how internal control is developed and performs. Many startups have no independent board at all, often just founders and an investor seat. The AICPA staff FAQs on SOC 2 and SOC 3 engagements, issued in December 2020, address exactly this case: how a service organization without an independent board affects the auditor's opinion on the suitability of design. Read the question and its answer before you assume the gap is fatal. The practical question for you is not whether you have an independent board, but what substitute oversight your auditor will accept and how you will prove it happened. Ask your CPA firm to state that treatment in writing before fieldwork begins, including what evidence it expects.

Practical alternatives to ask the auditor about include documented management oversight, where a written charter or governance section names who reviews control performance and how often. A named executive owner for the control environment, such as the CEO, CTO or a designated officer, gives the auditor a single person accountable for CC1 and CC2 activities. Periodic reviews of control results, with dated minutes showing the reviewer saw access review outcomes, open vulnerabilities, incidents and exceptions, turn oversight into testable evidence. Some companies add an outside advisor or investor reviewer who receives the same results and signs off on them. Each option needs a record. Without minutes, sign-offs or a dated review log, the auditor has nothing to test and will likely describe the oversight as a gap.

Treat this as a decision to document, not a formality. Choose one oversight model, write it into your governance documents, schedule the reviews and keep the minutes from the first review period onward, since a Type 2 examination tests operation over time. (Illustrative: a three-person company might have its CEO review access and incident logs each quarter and send the summary to an advisor who initials it.) Agree on what counts as sufficient reviewer independence and what happens if the reviewer is also the person who runs the controls, because the auditor will examine that overlap closely.

Choosing compensating controls the auditor can test

When one person can build, deploy and administer production, no single control can separate the roles, so the design relies on a second party or a system record that sees the actions of that person. The organization decides who reviews, how often, and what is reviewed. The auditor tests whether the review happens, covers the right population of changes, and is performed by someone other than the engineer.

Independent review of production changes: A named reviewer, such as an outside contractor, advisor or a non-engineering officer, reviews a periodic log of production deployments and configuration changes and signs off on them.
Logged approvals in version control: Changes go through pull requests that the engineer cannot merge alone, with the approval recorded before deployment.
Automated alerts on privileged actions: Alerts route to the reviewer and the engineer for root access, key rotation and changes to logging settings.
Evidence the auditor will request: The review population from the cloud audit log, sign-off records with dates, sampled pull requests, and alert configurations plus sample alert tickets.

Confirm with your auditor whether an independent reviewer outside the engineering function is acceptable for your design, and how sampling will apply when the population is small.

Assigning authorities and documenting them

A small team needs a written record of who may approve access, changes and incidents, because CC1.3 and CC6.3 look for defined, assigned and limited authorities even when the same person holds several roles. Start with a responsibility matrix that lists each recurring decision (granting production access, removing a leaver's accounts, approving a production release, declaring a security incident, approving a vendor) and names one primary owner and one backup for each. Next to each name, state the limit: for example, whether the approver may also be the requester, and what the backup does when the primary is unavailable. The matrix is the document an auditor will walk through first, so it should match what the team actually does in the ticketing system and cloud console.

Reporting lines matter for the same reason. CC1.3 asks the organization to consider all of its structures and to establish reporting lines, so draw the chart even if it has four boxes. Then write a short role description for each person with security responsibilities, covering what they own, what they may approve, and what they must escalate. Have each person sign or accept the description electronically, and keep the signed copies with the policy set described elsewhere on this page. Unsigned or undated role descriptions are weak evidence, because an examiner cannot tell which version was in force during the observation period.

Both documents go stale quickly when headcount changes. Set a recurring review, tied to hires, departures and role changes, and record each revision with a date and approver. Confirm with your CPA firm how it will sample these records and which period it expects them to cover, since a Type 2 examination tests whether assignments were followed throughout the period, not only on the day they were written. A useful check is to pick three recent approvals from the ticketing system and confirm that each approver held the authority the matrix gave them on that date.

How to build segregation of duties in a small team

This sequence turns informal habits in a small engineering team into documented, gated and dated evidence that an auditor can test against the segregation of duties points of focus in CC5.1 and the access criteria in CC6.3.

Map privileged actions in production and source control
List every action that could change production or the code that reaches it: deploying to production, merging to protected branches, changing cloud IAM roles, rotating secrets, altering database access, editing CI/CD pipelines and approving infrastructure changes. Work with the engineers who actually perform these actions, because the documented process often differs from practice. The output is a privileged action register with one row per action, the system it touches and the current way it is performed. The step is done when the founder or technical lead has reviewed the list against the cloud console and repository settings and no action is missing.
List who can perform each privileged action
For each row in the register, export the people and service accounts that hold the permission today, using cloud IAM reports, repository role listings and CI/CD administrator lists. Record shared accounts, long-lived keys and anyone with more access than their role needs. The output is an access matrix that shows, for every privileged action, the named holders and how each got their permission. The step is done when each holder is either confirmed as needed or flagged for removal, and the flagged items are assigned to an owner with a date set by the company.
Decide which actions need a second person or a gate
Using the matrix, decide for each action whether a second person must approve it, whether an automated check can stand in, or whether the person performing it should be the only one allowed to do it with logging. Where a team has only two or three engineers, a single person may hold a privilege that cannot be split, so the decision should record a compensating control such as mandatory peer review of the change after the fact, alerting on the action and a review of those alerts by someone else. The output is a decision record per action that names the control, its owner and the reason. The step is done when leadership signs the record and the record lists every exception that the auditor will need to understand.
Implement the gates and remove unneeded access
Configure the approved controls: branch protection requiring a reviewer who is not the author, separate deployment roles or environments that require approval, least-privilege IAM roles assigned through groups, multi-factor authentication for administrators, and alerts for changes to production permissions. Remove the access identified as unnecessary in the matrix. Keep each configuration as code or a screenshot with a timestamp. The output is a working set of gates plus a change log of access removed. The step is done when a test change confirms that the gate blocks the action it should block and that the record appears in the logs.
Run the controls and collect dated evidence
Once the gates are live, every privileged action performed during the observation period should leave a record: the approved pull request, the reviewer, the deployment approval, the access grant with its ticket, and the periodic access review signed by someone other than the person whose access is reviewed. Store these records in one place with dates, and reconcile them against the register each period to catch actions that bypassed the gates. The output is a dated evidence set that shows the control operated, including any exceptions and how they were handled. The step is done when the reconciliation for each period has been reviewed and signed.
Have the CPA firm test design and operating effectiveness
Walk the CPA firm through the register, the decision records and the gates so it can test whether the design addresses the criteria. For a Type 1 report, the auditor tests the design as of a date. For a Type 2 report, it also samples evidence across the observation period to judge whether the controls operated. Confirm early with the firm how it will treat compensating controls and single-person privileges, because those decisions shape the sample. The output is the auditor's testing results and any exceptions, which the company should answer in writing. The step is done when the firm has concluded and management has accepted the findings in its representation letter.

Questions small teams ask about segregation of duties

Can a two-person company pass a SOC 2 examination?

Yes, a small company can pass, but the auditor tests whether the controls work, not whether the team is large. With two people, one person often builds and deploys code, and the other reviews it, so the review step has to be real and recorded. Where one person cannot be separated from a duty, the company needs a documented compensating control, such as a second reviewer outside the team or a logged approval that a higher authority checks. The criteria most affected are CC5.1 and CC6.3, which ask for segregation of duties to be considered when access and control activities are designed. Ask your auditor early which roles are in conflict and what evidence they expect for each one.

What must a compensating control show to satisfy an auditor?

A compensating control must reduce the same risk that the missing separation would have reduced, and it must leave evidence that the auditor can test. In practice that means four things: a defined owner, a defined trigger or frequency, a record of each occurrence, and a review of exceptions. For example, if the engineer who merges a change also deploys it, a logged deployment approval by a second person, plus a periodic review of deployments against merged changes, gives the auditor something to sample. A control that exists only in a policy document usually fails because nothing shows it operated during the observation period.

Does a SOC 2 report require an independent board of directors?

No, a SOC 2 does not require an independent board, but the absence of one shapes how the auditor evaluates the control environment. CC1.2 restates the COSO principle that the board is independent of management and oversees internal control. A small company with an owner-led board can still meet the intent by setting up a documented oversight routine, such as a recurring security review where a named person outside day-to-day operations reviews risks, incidents and access, and minutes record the review. AICPA staff FAQs issued in December 2020 address how a lack of an independent board affects the opinion on suitability of design, so raise this with your CPA firm before fieldwork.

Can the auditor design our controls for us?

No, the auditor cannot design your controls. The organization owns its controls and its system description, and management makes the assertion that the examination tests. An independent CPA firm evaluates the design and tests operating effectiveness, and it can explain what criteria require. Under AT-C section 205, the service auditor also obtains written representations from management. An implementation partner or consultant can help you draft a control matrix and set up evidence collection, but the auditor must remain independent of that work, so confirm with the firm what preparation it can accept without impairing its independence.

What must the team do itself, and what can a partner handle?

The team must own the decisions, and a partner can prepare systems and evidence. Decisions that stay in-house include who holds each authority, which risks the company accepts, which compensating controls it adopts, and who signs the management assertion. Work a partner can typically prepare includes configuring access reviews, setting up logging and ticketing so approvals are captured, documenting the control matrix, and building evidence folders. Fixed-scope engagements make this split explicit: DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, which only an independent auditor can do. Agree the split in writing before work starts.

How does the auditor sample approvals when we have few changes?

With a small population, the auditor usually tests a larger share of the items, sometimes all of them, so every approval must be complete. The auditor selects samples from the population of changes, access grants or reviews that occurred in the period, then checks that each sampled item has the required approval recorded before deployment. A common failure is an approval given in chat, after the fact, or by the same person who made the change. Ask your CPA firm for its sampling approach and sample sizes in writing, since these depend on the frequency of the control and the firm's methodology, not a fixed rule.

What changes when moving from a Type 1 report to a Type 2 report?

A Type 2 report adds testing of operating effectiveness over an observation period, so the segregation controls must work consistently across that whole period, not only on the examination date. A Type 1 report covers the description of the system and whether controls were suitably designed as of a date. A Type 2 report adds an opinion on operating effectiveness over a period. For a small team, this means a compensating control that was set up the week before the Type 1 date will be tested on every occurrence through the period. Plan the observation window, collect evidence continuously, and confirm the period length with your auditor before you commit to dates.

What an implementation partner can and cannot do here

An implementation partner prepares the systems and evidence, but it cannot make the organization's control decisions or issue the report. DeployOpen can configure the tooling a small team needs to separate duties on paper and in practice: branch protection and required reviewers in source control, approval gates in the deployment pipeline, role groups and conditional access in the identity provider, and ticketed access requests for production. It can also set up the logging that shows who approved what, and assemble evidence packages that map each approval, access review and exception to the control it supports. The organization still decides who holds which authority, who can approve their own change (in a three-person company, often nobody can without a compensating step), and which reviews are performed and signed.

The organization also owns the policies, the risk assessment and the board or founder oversight that the common criteria in CC1 expect. A DeployOpen engagement is fixed in scope and does not change those ownership lines. Only an independent CPA firm can examine the system and issue a SOC 2 report, and the firm decides which compensating controls it accepts after testing them. Ask any partner to state in writing which deliverables are configuration, which are evidence and which are decisions that remain with management.

Engagement does not guarantee a clean opinion. A well-configured approval gate still produces an exception if the reviewer approved changes without reading them, or if an access review skipped a leaver. Before work starts, ask the auditor to confirm in writing which compensating controls it will test, and plan for the reviews to run on schedule through the whole observation period, since a Type 2 report depends on that operating evidence rather than on setup.

What delays small-team SOC 2 projects

Most delays on a small-team SOC 2 do not come from missing tools. They come from roles, approvals and oversight that exist in practice but were never written down or tested. The cards below cover the pitfalls auditors meet most often and the step that avoids each one.

Founders holding every admin right

When the same two or three people hold production, cloud, identity and code-repository administrator rights, the segregation of duties described in CC6.3 cannot be shown. Auditors look for a list of privileged accounts and a reason each person needs them. Before fieldwork starts, export the admin roles from each system, remove what is not needed, and record who approves any future grant.

Undocumented authorities

If nobody has written down who may approve access, change production or accept a risk, the reporting lines in CC1.3 are unclear and every approval looks informal. Auditors ask for a responsibilities document and a sample of approvals that match it. Write a short authority matrix that names each role, its limits and its backup, and have leadership sign it.

Self-approved changes

When an engineer merges code, deploys it and reviews it, the change management evidence under CC8 shows no independent check. Small teams often believe a chat message counts as approval. Configure branch protection so a second person must review each change, and require that the reviewer is not the author. Keep the pull request history as the change record.

No independent board oversight

A company without an independent board still needs a way to show that management is overseen and that internal control is reviewed. The AICPA staff FAQs from December 2020 address how a lack of an independent board affects the opinion on suitability of design. Decide early who performs the oversight role, such as an advisor or investor director, and schedule and minute a periodic review of controls and risks.

Compensating controls designed late

A compensating control is a substitute for a control a small team cannot staff, such as a second reviewer. If it is designed after the examination period has begun, the auditor cannot test it across the whole period, and gaps appear in the report. Choose compensating controls before the period starts, write them into the control matrix, and confirm with the auditor that they are testable.

Access reviews skipped by lead

Access reviews are the usual proof that roles still match responsibilities. When the person who grants access is also the only person who reviews it, the review is weak evidence. Assign the review to someone outside the grant process, such as an advisor or finance lead, run it on a fixed schedule, and keep the signed export and the removals it triggered.

How DeployOpen prepares segregation of duties evidence

DeployOpen works with small SOC 2 teams to set up the systems, access paths and records that show who can do what, and who reviews it. The company prepares systems and evidence for the examination, while the organization owns its controls and an independent CPA firm issues the report.

How we scope

Engagements are fixed-scope, with the roles, systems and criteria to be covered agreed in writing before work starts.
The written scope lists which people hold production, deployment and access-approval rights and which oversight roles are being evidenced.
Scope also records which compensating controls are proposed, so the CPA firm can review and test them before fieldwork.

How we build

We configure role-based access in self-hosted systems so engineers can request changes but cannot approve their own production access.
We set up logged approval steps for code merges, deployments and access grants that produce records an auditor can sample.
We document oversight routines, such as periodic access reviews and management sign-off, in a form that shows who performed them and when.

How we hand over

We deliver a control matrix that maps each segregation or oversight control to its owner, system, frequency and evidence source.
We provide evidence packages with exported logs, access lists and review records, organized for the CPA firm's sample requests.
We walk through the documentation with your team so management can explain each control and its limits during the examination.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainer work can keep access reviews, role changes and approval records current between audit periods.
Before any changes to roles or systems, confirm with your CPA firm how the change affects the control design and the evidence period.