T

The auditor's first request was not about policies. "Your access control policy says user permissions are reviewed quarterly. Show me the March review."

There was no March review. The policy describing the March review had been generated in April.

Compliance platforms are good at the half of this that is documents. The half nobody costs is the ISO 27001 engineering requirements a startup has to build itself, which is the machinery that produces dated, attributable records proving a control actually ran. Policies take a weekend. Evidence takes somewhere between nine and fifteen engineering weeks, it has to have been running for months before the auditor arrives, and it is the only part of the project that cannot be compressed at the end.

That distinction is the whole article, and it costs teams a quarter to learn in the room.

Why does a green compliance dashboard still fail the audit?

Certification runs in two stages, and the platforms are optimised for the first one.

Stage 1 is a documentation review. Does the ISMS exist on paper, is there a Statement of Applicability, has management signed the scope. A compliance platform will get you through Stage 1 comfortably, because Stage 1 is a document problem and documents are what it generates.

Stage 2 is an implementation audit. The auditor picks controls from your Statement of Applicability and asks for proof they operated during the period. Not proof they exist. Proof they ran, on specific dates, with a named person attached.

The shape of the request is always the same. Three access reviews from the last twelve months, please. The change record for the deploy on 14 March. Who approved the production database access this contractor was given, and on what date was it revoked. Each of those is a query against a record that either exists or does not, and no amount of policy writing creates one retroactively.

ISO/IEC 27001:2022, published in October 2022, restructured Annex A into 93 controls across four themes, down from 114 in the 2013 edition. Organisations holding a 2013 certificate had until 31 October 2025 to transition. The renumbering caused a lot of noise and changed very little about the engineering, because the controls that consume engineering weeks were always the same five or six.

What do I actually have to build?

The build list is short and mostly unglamorous, which is why it gets underestimated.

Start with audit logging that somebody cannot quietly edit. If your audit trail is a table in the same Postgres instance your application writes to, then anyone with database credentials can alter the record of what they did, including the person the record is about. Auditors ask directly who is able to modify these entries, and "nobody would" is not an answer. The fix is architectural: ship the events somewhere the write path and the retention policy are controlled separately from application credentials. S3 with Object Lock in compliance mode, or a log archive account with a CloudTrail trail the application role cannot touch.

Worth separating two things that get conflated here. The traces and metrics you already ship are operational telemetry with a 15 or 30 day retention and no reliable actor attribution, which is a different artefact from an audit log, even though both are called logging and both go to a dashboard. If you have not built the operational half either, logs, metrics and traces is the cheaper of the two projects and you want it regardless.

Then access control that survives questions rather than a demo. Demo RBAC is a roles dropdown in the admin UI. Audit RBAC means you can produce, for any named user, every permission they currently hold, when it was granted, who approved it, and the record of the last review that confirmed it is still appropriate. Joiners and leavers are usually handled, because both are visible events that somebody announces in Slack. Movers are where everyone fails: someone shifts from support to sales, gains the sales tooling, and keeps the support console with its customer data export button for the next two years.

Encryption at rest is mostly a writing task, provided you are on managed services. "We use RDS encryption" answers a question nobody asked. What gets asked is who holds the KMS key policy, whether the people who can decrypt are a different set from the people who administer the data, how rotation happens, and whether any of that matches the sentence sitting in your policy document. Self-host your databases and this stops being a writing task.

The fourth is a restore you have genuinely performed, and it gets its own section below because it is the one that fails in the room.

The fifth is change management enforced in CI rather than described in Notion. Your policy says changes are peer reviewed and tested before production. The auditor asks for the branch protection configuration and a list of every commit merged to main in the last quarter without an approving review. Git history answers that question honestly whether you want it to or not, which makes this the control you cannot backfill in the final fortnight.

Nine to fifteen weeks depending on where you start. That range is the number founders are never given, and it is why the certification that was supposed to take a quarter takes three.

What does a realistic 90-day sequence look like?

Scope first, and treat it as an engineering decision rather than a paperwork one.

Days 1 to 15 go on the Statement of Applicability and the ISMS boundary. Descoping is the single most valuable move available to you, because every system inside the boundary generates evidence obligations forever. An internal analytics stack in a separate AWS account that never receives customer data can sit outside the scope if you can defend the boundary, and defending it requires knowing what your infrastructure is actually made of, which is a surprisingly common gap. A written inventory of your infrastructure is the first artefact, and it feeds the asset register the standard asks for anyway.

Days 15 to 45 go on the controls that produce records over time. Audit logging, change management in CI, the first access review. These go first because they need to have been running before the auditor looks, and three months of history cannot be manufactured in the last week. Certification bodies generally want to see the ISMS operating rather than merely existing, and in practice that means a period of records behind you.

Days 45 to 70 are the ones with a fixed cost and no accumulation requirement. The restore drill. Key handling documentation. The subprocessor inventory, which turns into a real engineering task the moment you check it against outbound network calls instead of against memory.

Days 70 to 90 are internal audit and management review, both mandatory clauses of the standard rather than optional good practice, then Stage 1.

Here is the scheduling detail that catches people. If the buyer asked for SOC 2 Type II rather than ISO 27001, ninety days does not get you a report. Type II covers an observation window, commonly three to twelve months, so the earliest a 90-day project can deliver is the day the window opens. A Type I attestation is point in time and can land inside the quarter. Find out which one the contract actually says before you plan anything, because the two words differ by roughly six months of calendar.

Data residency deserves its own note, because it appears as a control in your Statement of Applicability and as an architecture problem in the codebase. If the buyer's questionnaire asked about storage location as well as certification, you are dealing with a second project about where your customer data physically lives, and it is the one with the longer lead time of the two.

What do auditors test hardest?

The restore. Every time, and for a good reason: it is the control most often found to be theatre, and it is trivially falsifiable in a way policies are not.

A backup you have never restored is a file. It has the size and the timestamp and the reassuring green tick in the console, and none of those properties are the one you are paying for.

Every failure mode here is silent. Run pg_dump under a role that lacks permission on a schema somebody added later and it produces a smaller dump each year without ever raising an error. Point the job at a replica that quietly stopped replicating in February and you get a file that is internally consistent and eleven months stale. Then there is the restore that works perfectly and takes eleven hours against a stated RTO of four, which is a failed control with a green log line. And the encryption key stored in the same account as the data, which protects you in every scenario except the one the backup exists for.

The worst one I have seen ran cleanly for four years. Nightly dumps, 1.4 TB sitting in S3, the job green every single morning. The first genuine restore attempt failed because the dump role had never been granted read on two schemas added during a 2023 feature build. Four years of backups, none of which contained the tables the company had been built around since.

The auditor's question is narrow and you can rehearse it: when did you last perform a restore, who performed it, how long did it take end to end, and what did you find. Run one this month, take notes while it is going badly, and file the notes. A restore test that surfaced three problems is stronger evidence than one that reports everything perfect, because the second one reads like it never happened.

Which parts of this are worth doing anyway?

Some of it is pure compliance cost with no engineering benefit, and saying otherwise insults anyone who has done it.

Writing Statement of Applicability justifications is pure cost. Awareness training completion records are pure cost. Physical security controls are pure cost for a company whose entire estate is a managed cloud account and a co-working membership, and you will still write something about visitor logs. Supplier questionnaire filing is pure cost. None of that makes your system better by a single percentage point.

Four of them are worth the money independent of any certificate. The restore drill, because you were going to find out eventually and this way you choose the date. Change management in CI, which is a two-hour configuration change that removes a category of incident. The quarterly access review, which finds the contractor who left in 2024 and still holds a production credential, and it finds one nearly every time. The subprocessor inventory, because a list of every external service your code calls is genuinely useful and almost nobody has one.

We do this engineering work for clients, which makes the next paragraph awkward to write and worth trusting for the same reason. If a single deal is your only driver and the contract is under roughly €50,000 a year, full ISO 27001 certification is the wrong instrument. Ask the buyer's security team directly whether a completed CAIQ, a recent penetration test report, and a signed DPA clears their bar. Frequently it does, and it costs a small fraction of a certification. We have talked two clients out of the full project on exactly that basis and both of them closed the deal they were worried about.

Certification is worth it when you expect the question repeatedly. Once is a questionnaire. Four times a year is a process, and at that point the certificate stops being a cost and starts being the thing that shortens every subsequent security review. This is also one of the other six things that stall an enterprise deal, and they tend to arrive together rather than one at a time.

Questions CTOs ask before Stage 1

How long does ISO 27001 actually take for a startup? Six to nine months from a standing start is normal for a team of five to twenty-five. Ninety days is achievable only if audit logging, change control and access reviews already produce records, because those need history behind them and history cannot be compressed.

Is Vanta or Drata enough to get certified? They will carry the documentation, the policy set and the evidence collection plumbing, which is real value. They cannot build immutable audit logging, they cannot perform your restore test, and they cannot create access review records for a quarter that has already passed.

What is the difference between ISO 27001 and SOC 2 in terms of engineering work? Close to none. The controls that consume engineering time are the same five. The difference is in the reporting format and the timing, since SOC 2 Type II requires an observation window while ISO 27001 certifies the management system.

How many engineering weeks should I budget for ISO 27001? Nine to fifteen for a team already on managed cloud services with sensible defaults. Add three to six if you self-host databases or if access is granted ad hoc through direct console permissions.

Can I get certified in 90 days? Stage 1 in 90 days is realistic. Certification usually is not, unless your controls have been operating and generating records for the preceding quarter without you having called them controls.

Whatever the dashboard says this morning, the number that decides your Stage 2 is the duration of a restore nobody has run yet. It is the one piece of evidence available to you today, and the only one an auditor cannot be talked out of asking for.