SOC 2 With No Security Team: Which Controls Are Code and Which Are Paperwork

The SOC 2 in that email is the report a business customer asks a software vendor for, the one the AICPA publishes criteria for. The same three letters also sit on SOC 1 and SOC 3, which are different reports, and on the monitored room some large companies run. This page is about none of those.

The email is usually one line. Somebody in procurement, or the person doing security reviews at a company that has just agreed to buy from you, asks you to send your SOC 2 report. You have a working app that AI tools built. You have no security person, no compliance person, and quite possibly nobody who reads code. This is one line on the list that a first enterprise customer brings with them, and the other lines land in the same week.

So you read the guides that rank for this, and they say the same five things: learn the criteria, run a gap assessment, fix the gaps, buy a compliance tool, book an auditor. They are written for a company that already employs somebody who can answer show me your change management process without flinching. Across the eight front-page results read on 3 September 2026, none tells you which part of this is a person writing documents and which part has to become true inside the thing you shipped.

The second part is what this page is about.

A SOC 2 controls list asks for two kinds of evidence. Most of it is written down by a person: policies, an access review, a list of the vendors you use. A smaller part has to be true in the software, and the nine control classes below sort any request into those two piles.

What your customer is asking for when the email says SOC 2

They want a report about your company written by an accounting firm, not a certificate you can buy. The AICPA and CIMA download page for the Trust Services Criteria, read on 3 September 2026, names the document the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022), and its description says plainly what those criteria are for: a CPA uses them when examining an organisation’s controls and reporting on what was found. That is the shape of the thing your customer wants. An examination, and an opinion signed by a firm, rather than a badge anybody issues.

The same description names five subject matters the controls can be judged against, and joins them with “or” rather than “and”: security, availability, processing integrity, confidentiality, or privacy. A report therefore says which of the five it covers. As of 3 September 2026 that page does not state which of them is required or usual, so neither does this one.

If the request in your inbox specified a type, that word changes what the report attests and when you can hand one over. Whether a customer’s request actually obliges you to get a report, and how long the observation period runs, is a decision of its own. Both of those are answered away from here, because this page has one job: telling you which parts of the answer are work in your app.

One thing to rule out before you spend real effort on it. If your customer will accept the report your platform already has, you are in a different conversation entirely, and it is a short one. What a platform’s own report covers, and why it is never your report, is answered where the platforms’ paperwork is read.

The trust services criteria, and why every SOC 2 checklist you have found looks different

The criteria are published as criteria used to evaluate controls, which is what the AICPA’s own description of them says, rather than as a numbered list of controls to go and implement. The control lists that circulate free are each a publisher’s own mapping onto those criteria, and that is why two SOC 2 requirements checklists rarely contain the same rows in the same order.

You cannot settle the difference by going to the source, and the reason is worth knowing before you spend an evening trying.

As of 3 September 2026, the AICPA’s own page for the Trust Services Criteria describes the document and offers it as a download behind a free account; the criteria text itself does not render to an automated read, and a plain request and a browser-shaped request both returned the description page rather than the document.

The direct file path for the document was tried the same two ways on the same day: under www.aicpa.org it returns a not-found page, and under us.aicpa.org it returns the description page again rather than the file.

That limit decides what the rest of this page may say. It quotes no criteria text, prints no control count, and invents no category, point of focus or numbered criterion. If a customer’s spreadsheet references CC6.1, the CC is how the common criteria are referenced and the number points into that document. What the numbered text actually says is not restated here, because it was not readable, and a page that guesses at it is worse than no page.

What survives the limit is the part nobody publishes anyway: the shape of the evidence. A list can vary in every row and still ask for evidence in only two forms.

Two halves of a controls list: what somebody writes down and what the app has to do

Take any control list you have been sent and read it one row at a time, asking a single question: does this row want a document that describes what happens, or does it want the software to actually do something?

Rows in the first pile are satisfied by a person and a word processor. A policy, a record that access was reviewed on a date, a list of the companies your product depends on, a note of who joins and who leaves and when their accounts were closed. None of it is fun and all of it is finishable. Given a template, the written half can be produced by the person who owns the product, with nobody technical involved.

Rows in the second pile cannot be written into existence. If nothing in your app records who read a customer’s record, no document creates that record retroactively. If no test ran before the last deploy, no policy makes it so. This is the pile that surprises owners of AI-built apps, because the app works, customers pay, and nothing about the day-to-day suggests that the parts an auditor asks about were never built.

A controls list does not ask whether the code is good. It asks whether you can show what happened.

Everything below is read, not run. The criteria come from the AICPA’s own published page for them, the platform behaviour from a builder’s own documentation, each read on the date given beside it, and the pattern counts from a fixed set of applications reviewed in June and July 2026 with the denominator stated. I have never audited anyone for SOC 2, has never passed one, does not sell a service that prepares anybody for one, and nothing on it substitutes for advice from a lawyer or an auditor, or decides whether any given app would satisfy any given examination.

Which SOC 2 controls are code, and which are paperwork?

Nine classes of control turn into work inside the app rather than work in a document: who can reach production data, whether a change was reviewed, whether it was tested, what gets recorded, whether vulnerable versions get replaced, encryption, backup and restore, removing access, and a route for an incident. The table says where each lives.

Read the third column as an address rather than a verdict. It says where the evidence would be if it exists. It does not say whether your app has it, and it says nothing about whether any particular auditor would accept what is there. That judgment belongs to the firm doing the examination and to nobody else.

Row three is the one that catches AI-built apps hardest. In the fixed set of applications reviewed in June and July 2026, a fixed cohort of 26 apps whose findings were confirmed into a single ledger, at least 18 of the 21 third-party apps inside that ledger had no automated test in working order. A change-testing row asks you to point at the check that ran before a release went out, and in most of those applications there was nothing to point at.

Two more things the table is quietly saying. The first is that every row in the third column is a settings screen or a file, which means somebody can go and look today without reading a line of code. The second is that some of what those rows ask for is decided by a plan rather than by effort: what a platform retains, what it lets you configure, and what it will schedule for you are set by what you pay it, and no amount of care changes them from inside the app.

SOC 2 password requirements is one of the phrasings people search in this family. The specific wording sits in the document that does not render, so what this page can honestly say is where such a rule would be checked: in the authentication settings of whatever runs your logins, alongside the setting that decides whether a leaked password is accepted at all, rather than in a paragraph of a policy that says passwords are important.

The evidence an auditor asks for, and where a generated app keeps it

An examination runs on evidence, and for the code half the evidence is usually a settings page somebody has to open. Builders document their own settings differently, and the honest way to read any of them is to open the vendor’s own documentation and check the current wording rather than trust a summary. One worked example, from a single builder’s own pages, shows the shape.

Lovable’s own security documentation, read on 3 September 2026, states that scheduled deep scans are something workspace admins and owners on Enterprise plans can set to run automatically across selected projects. The same page describes a leaked-password check that an owner switches on for email and password authentication, which the page says checks user passwords against the Have I Been Pwned database and prevents users from choosing known compromised passwords. Neither of those is a property of the app as generated: both are a decision somebody made, on a date, in a dashboard, and the date is the part an examination cares about.

The same page carries the sentence most worth reading twice if a report is what you need. Its optional connector for penetration testing, in its own words, “generates a shareable report structured for SOC 2, ISO 27001, and security questionnaires”. That is a genuinely useful artifact and it is not the thing your customer asked for. A findings report describes what a tool looked at in your app. The report in the email is an accounting firm’s opinion about your company’s controls, and no product generates one.

That difference is where most of the confusion on this subject starts, and it has an older cousin. The habit of checking that a written claim matches what the code does is worth having before an auditor asks, and it has its own page.

When the request arrives as a spreadsheet of rows to answer rather than a report to produce, the form itself has its own answers, and the two are not the same job even when the same customer sends both.

What is a SOC 2 compliance checklist for, and what can it not tell you about your app?

A SOC 2 compliance checklist is a vocabulary list and a running order. It tells you what the rows tend to be called, what a reviewer expects to exist, and roughly what sequence people work in. What it cannot tell you is whether the software half of those rows is already true inside your own app.

There is a reason you keep finding one. On 3 September 2026, three of the eight results on the front page for soc 2 for startups led with a free downloadable checklist, and the checklist phrasing is one of the most searched in the whole family. A list is the easiest thing to publish about a subject whose source document sits behind an account, and it is a reasonable thing to want. Most of what ranks for compliance for startups is published by the companies selling the tooling, and a SOC 2 guide written for a SaaS that already has a security team answers a different question than the one in your inbox.

Use it for what it is good at. It gives you the customer’s vocabulary, so you stop guessing what a row means. It shows you the written half in one view, which is the half you can finish. It gives you an order of work, which matters when the alternative is answering the email at midnight in whatever order panic supplies.

Then notice what happens when you reach a row like changes are tested before release or access to production data is restricted and reviewed. The list has told you the row exists. It has not told you whether your app does it, and it cannot, because it has never seen your app. That is the row where a self-assessment version stops helping too: ticking a box you filled in yourself is not the evidence, and no reviewer treats it as evidence.

Nothing on this page is offered as a downloadable list, template or document. The table above is the closest thing to one, and its whole point is the third column, which no generic list can fill in for you.

Gap assessment, readiness assessment, risk assessment: three names, three different jobs

Three phrases with real search volume behind them, and people use them as though they were interchangeable. They are not, and the difference matters when somebody quotes you for one.

A gap assessment compares what exists against a control list and produces the difference. A readiness assessment is the name the sellers on these searches put on a paid version of that same comparison, usually with a plan attached and usually sold as the step before the audit itself. “Readiness” in this territory is their word for a product they sell, and it is used here in that sense only. A risk assessment answers a different question entirely: what could go wrong with the thing you run, how bad would it be, and what are you doing about the worst of it. The first two measure you against somebody’s list. The third asks you to think about your own product.

Two practical consequences follow. If a customer or an investor uses one of the three words, ask which of the three jobs they mean before you price anything, because a founder who buys the wrong one pays for a document nobody wanted. And if you are choosing which to do first with limited attention, the gap comparison is the one you can partly do yourself with the table above, one row at a time, writing down the address of the evidence rather than a verdict about it.

None of this is a recommendation of any seller, and I sell none of the three.

How to get SOC 2 compliance from here, and what the auditor does not look at in your code

The searches say how to get SOC 2 compliance and how to become SOC 2 compliant, and both phrasings hide the same misunderstanding: that there is a state you enter rather than a report somebody writes about a period of your company’s life. On the AICPA’s own wording, the criteria exist for use in attestation work to evaluate and report on controls. The object of the examination is your controls. It is not a grading of the code your tools generated, and nobody reads your components looking for style.

What the examination covered is what people mean when they say SOC 2 scope, and it is settled with the firm doing the work rather than guessed at from a page like this one.

Which means two things at once for an owner with no technical staff. The good news is that nobody is going to open your repository and judge the quality of what an AI tool wrote. The less good news is that the questions asked instead are ones your app has to answer with its behaviour: what it records, what it restricts, what it restores, and whether any of that can be shown for a date in the past rather than for today.

It also explains why buying code work does not produce the report. A person who reads your code can tell you what is true in the app and can change what is not. The report comes from an accounting firm that examines your controls and issues its own opinion, and no amount of engineering substitutes for that opinion.

An examination asks your app for a past tense. Most AI-built apps can only answer in the present.

Preparation, then, is two lists rather than one programme. The written list is the one the policy templates people search for are genuinely good for: they fill the document column quickly and they are the cheapest part of this. The other list is the third column of the table above, walked one address at a time, with the current state of each written down and dated. An owner who has done that second walk can hold a sensible conversation with an auditor, a compliance vendor or a customer, because the honest answer to most rows stops being a guess.

What all of this ends up costing, once an auditor and a compliance tool are both quoting, is a separate question with separate numbers, and it belongs on the page that collects those numbers rather than in a guess here.

Where the checking and the fixing already have their own pages

Four questions arrive next, and each one is somebody else’s page rather than another section here.

Deciding whether to buy an outside review at all, and which of the five things people call an audit you are being asked for, is settled on its own page. What a written review should contain, down to the evidence beside each finding, is set out where that process is documented. The order to repair those boundaries in, and the test that proves each repair held, is a sequence somebody else has already written down for you. And if the same email also asked for a penetration test, that is a different request with different evidence behind it.

Common questions about SOC 2 with a small team

Do you need a security team to get SOC 2?

Not in the sense of hiring one, and the source document does not settle the question either way: as of 3 September 2026 the AICPA’s own page for the Trust Services Criteria describes control criteria for use in attestation work and says nothing about staffing. What the work needs is somebody who can write the documents and somebody who can change settings inside the app. On a small product those are often the same person, and the second job is where an owner who cannot read code runs out of road.

Which SOC 2 controls are actually changes to the app?

Nine classes, set out in the table above: access to production data, change review, change testing, activity records, vulnerable dependencies, encryption, backup and restore, removing access when somebody leaves, and a named route for an incident. Each has an address in your app rather than in a folder of documents, and the useful first move is opening each address and writing down what is actually there.

Does SOC 2 cover AI features in my product?

A report names which subject matters it covers, and the AICPA’s page for the criteria describes those as security, availability, processing integrity, confidentiality, or privacy. No separate heading for AI appears in that list. What a reviewer usually means by the question is narrower and more answerable: what your product sends to a model provider, and what that provider keeps afterwards.

Is a SOC 2 compliance checklist enough to prepare with?

For the written half it is a reasonable working document. For the software half it cannot be, because a published list has never seen your app and cannot tell you whether a row is already true in it. Use the list for vocabulary and order, then answer the app-side rows by opening the settings screens they point at.

What is a SOC 2 readiness assessment, and who sells one?

It is the sellers’ name for a paid comparison of what you have against a control list, usually delivered with a plan for closing the difference. The compliance-automation vendors and audit firms that rank for these searches sell it under that name, and the word belongs to them. I do not sell one, recommend no seller here, and this page ranks nothing.

Does an auditor read the code an AI tool generated?

On the AICPA’s own wording the criteria are used to evaluate and report on controls, so the object of the examination is what your controls do rather than how the code is written. Nobody grades your components. The questions land instead on what the app recorded, what it restricted and what it can restore, which for an AI-built app is often harder to answer than a code-quality question would have been.

What does CC6.1 mean on the checklist my customer sent?

CC is how the common criteria are referenced, and the number points at one criterion inside the AICPA’s Trust Services Criteria document. The exact wording is not repeated here: as of 3 September 2026 that document sits behind a free account and its text does not render to an automated read, so any page quoting a criterion number back to you without the source is passing on somebody else’s summary of it.

Can I use my platform’s SOC 2 report instead of getting my own?

Sometimes as the answer to one row on a form, never as your own report. A platform’s report covers the platform’s own systems, and your app is a customer of that platform rather than part of it. The full version of that boundary is read out where each platform’s compliance paperwork is taken apart, including what a customer can and cannot do with a vendor’s report.

What is the difference between a policy and a control?

A policy is the document that says what is supposed to happen. A control is whatever actually makes it happen, which can be a person following the policy or a setting in the software enforcing it. An examination looks for the control and treats the policy as its description, which is why the app-side rows in the table above cannot be answered by writing a better document.