A first SOC 2 looks like a hundred tasks: turn on MFA, enable disk encryption, protect the main branch, rotate keys, write eleven policies. Most of those tasks are configuration. They have a right answer, a person or tool can carry them out, and a test confirms the result.

A small set of items has no right answer. Someone at the company has to choose, and an auditor will then test whether the company did what it chose. Those choices are the work that takes real time, and they cannot be handed to a tool or a consultant.

Decision 1: scope#

SOC 2 covers the systems and services you put in scope, and the report says what they are. The AICPA's Trust Services Criteria include Security as the base category and add Availability, Confidentiality, Processing Integrity, and Privacy as optional ones.

You decide:

Which categories. Security is the required base. Adding Availability means committing to uptime targets and testing them. Add a category when a customer asks for it, since each one adds controls to test.
Which systems. The production application, its cloud accounts, the code repositories, the identity provider, and the HR system are in scope for a typical product company. The marketing site's CMS is a decision.
Which environment. Whether staging holds production data decides whether staging is in scope.

A wide scope makes the audit longer and the evidence larger. A narrow one risks a report a buyer rejects. Pick based on what your next five customers ask to see.

Decision 2: the revocation deadline#

The criteria require that access is removed when it is no longer authorized. They do not say how fast. Your policy says, and the auditor tests against your number.

Choose a deadline for each case: a termination, a role change, a contractor whose contract ends. "Same business day" for terminations is a common choice for a team with an owner always available. If nobody is reliably online on weekends, 24 hours may be the number you can meet. The control tests your own commitment, so an achievable number you meet every time passes and an aggressive one you miss twice produces findings.

Write it into the access policy, and write who owns the action. This is the decision that CC6.2 findings usually trace back to.

Decision 3: who approves production changes#

Change management is CC8.1 in the criteria: changes to infrastructure, data, software, and procedures are authorized, tested, and approved. At ten people, the engineer who writes the code is often the one who merges it and deploys it.

You decide:

Who may approve a change to production. A named list, and a rule for what happens when the approver authored the change. Two engineers can review each other. A solo technical founder needs a different answer, such as a second reviewer who is an advisor or a contractor.
Which changes need an approval at all. Application code through a pull request is one class. A change to an IAM policy, a database migration, or a firewall rule is another, and you can require a named approver and a written reason for that class.
Where the approval lives. GitHub's protected branch settings can require reviews before merge, which gives you a recorded approval for code. Infrastructure changes need their own place for the approval to be recorded.

A rule that blocks every urgent fix at 2 a.m. will be bypassed, and a bypass is an exception you did not plan for. Which leads to the fourth decision.

Decision 4: exceptions#

Every control has cases where it does not apply or cannot be met on time. A contractor who needs an account before the background check returns. A legacy service whose credential cannot be rotated without downtime. A device that cannot run the management agent.

Decide in advance how exceptions work:

Who can grant one. A named person, who is not the person requesting it.
What it must record. The control, the reason, the compensating measure, and an expiry date.
How it ends. An exception with no expiry becomes the standard practice.

Auditors do not expect zero exceptions. They expect each one to have an owner, a reason, and a record. An undocumented exception is a failed control, and a documented one is evidence that the process works.

What can be delegated#

Once those four decisions are written down, the rest is configuration against them.

Enforcing MFA in Google Workspace or Microsoft 365.
Requiring pull request reviews and status checks on GitHub.
Turning on encryption and logging in AWS or GCP.
Enrolling devices in management and enforcing disk encryption and screen locks.
Removing departed users from Slack and the other tools.

Each item has a correct end state, can be tested, and does not need a founder's judgment. It needs someone with admin access and time, and then a read-back to prove it landed.

That split is how Deixic is organized. You write the policy and name the approvers. Deixic fixes failing controls inside that policy, waits for the named approver and a reason on the sensitive changes, refuses actions outside the authority you gave it, and keeps a receipt of each change. The four decisions above become the limits it works within.

Start with a one-page document#

Before the audit kickoff, write the four decisions on one page: scope, revocation deadline, approvers for production, exception process. Have the person who will sign the report review it. Everything else in the audit follows from that page, and the auditor will test every line of it.