SOC 2 controls you can check in code, and which you can't

SOC 2 is a report, not a certificate. An independent CPA firm checks your controls against the AICPA’s Trust Services Criteria and writes down what it found. A Type I report looks at whether the controls are designed well on one date. A Type II report looks at whether they worked over a period, usually 3 to 12 months.

For a software company, a lot of the evidence sits in the codebase and the systems around it. A lot more doesn’t. Knowing which is which saves weeks before an audit.

The criteria in short

Every SOC 2 report covers Security, the Common Criteria (CC1 to CC9). Availability, Confidentiality, Processing Integrity and Privacy are optional and added when customers need them.

The Common Criteria cover the whole company, from the board and hiring (CC1) to risk assessment (CC3) and vendors (CC9). Only some of them reach your code.

What code can show

Criterion	What the auditor wants	What it looks like in code
CC6.1 Logical access	Only the right people and systems reach data	Secrets kept out of source, strong password hashing, sensitive fields masked
CC6.6 External threats	Boundaries are protected	APIs that only accept requests from your own sites (restricted CORS)
CC6.7 Data in transit	Data moving between systems is protected	HTTPS everywhere, TLS certificate checks left on
CC7.1 Detecting weaknesses	Known weak spots are found and fixed	No SQL built from strings or other injectable patterns
CC7.2 Monitoring	Unusual activity can be noticed	Admin actions, data changes and AI calls write an audit log
CC8.1 Change management	Changes are approved and tested before release	Branch protection, required reviews, CI that runs checks, no debug mode left on

Some examples of what a scan finds:

export const stripeKey = "sk_live_...";                     // CC6.1, secret in source
const hash = md5(user.password);                            // CC6.1, weak password hash
app.use(cors({ origin: "*" }));                              // CC6.6, open to any website
new https.Agent({ rejectUnauthorized: false });              // CC6.7, TLS checks off
db.query(`SELECT * FROM users WHERE id = ${req.params.id}`); // CC7.1, injectable query

Each of these is a single line, and each one is the kind of thing an auditor or a customer’s security questionnaire will ask about.

What code can’t show

These need a policy, a record or a person, and no scan will produce them:

• Access reviews (CC6.2, CC6.3). Someone checks every quarter who has access to what, and signs a record.
• Onboarding and offboarding (CC6.2). Accounts are created on approval and removed on the last day.
• Risk assessment (CC3). A written review of what could go wrong and what you do about it.
• Vendor management (CC9.2). You know which vendors hold your data and you have checked them.
• Incident response (CC7.3 to CC7.5). A written plan, and proof it was tested or used.
• Policies and training (CC1, CC2). Security policies people have read, and security training they have done.
• Background checks (CC1.4) for people with access to systems.

For a Type II report, the auditor will sample these over the whole period. A control that started last month will show as an exception.

A practical order

1. Fix what code shows first. Secrets, hashing, TLS, CORS and query building are quick to fix, and they are the findings that look worst in a report.
2. Add the audit log early. CC7.2 needs history. A log you add the week before the audit has no history to show.
3. Turn on change management in your git host. Required reviews and CI checks on the main branch cover much of CC8.1, and the history builds up by itself.
4. Start the records now. Access reviews, offboarding and incident logs need months of entries for a Type II report.
5. Pick an auditor and a readiness date. Many teams do a Type I first and a Type II over the following 6 to 12 months.

What Lintsure checks

Lintsure’s SOC 2 rules look at the code side of CC6.1, CC6.6, CC6.7, CC7.1 and CC8.1. For CC7.2 it only checks that AI calls are logged; it doesn’t yet check audit logs for admin actions or data changes. Each finding names the file, the line and the criterion, and its report lists the outside-code items above so they don’t get lost.

It can’t tell you that you are ready for SOC 2. Only your auditor’s report can say how your controls performed. Lintsure helps you find the code problems before the auditor does.

See all rules or the SOC 2 overview.