A prospect's procurement team asks for your ISO 27001 certificate. You have 20 engineers, no compliance hire, and a standard that reads as if it were written for a bank. The temptation is to buy a stack of templates and hope.
ISO/IEC 27001:2022 is more forgiving of small organizations than its reputation suggests. Clause 7.5.1 says outright that the extent of documented information can differ with the size of the organization and the complexity of its processes. What the standard does not forgive is an ISMS that exists only on paper.
This article sets out what a first certification actually requires, the order to build it in, and the places small teams most often lose time.
What the certificate actually says
An ISO 27001 certificate states that your information security management system, within a defined scope, conforms to the requirements of the standard. Those requirements are clauses 4 to 10: context, leadership, planning, support, operation, performance evaluation, and improvement. Annex A is the reference list of 93 controls you compare your own control set against.
The certificate is issued by a certification body after a two-stage initial audit. It runs on a three-year cycle, with surveillance audits in the years between. If the ISMS idea is still abstract, start with what an ISMS is, in plain terms, and check that the body you hire is accredited.
Two things the certificate does not say. It does not say every Annex A control is in place, because you choose and justify your controls. It does not say you are secure. It says you run a management system that identifies risk, treats it, checks itself, and improves.
Choose a scope you can defend
Scope is the first decision and the one with the longest tail. Clause 4.3 asks you to define the boundaries and applicability of the ISMS, considering your context, your interested parties' requirements, and the interfaces with activities outside the scope.
For most startups the defensible scope is the product customers buy, plus the people, processes, and systems that build, run, and support it. That usually means everyone, because in a 25-person company almost everyone touches production or customer data.
Resist two opposite mistakes:
Scoping too narrow. Carving out the support team or the data pipeline to reduce work gives you a certificate that does not cover what the buyer cares about. Buyers read the scope statement on the certificate.
Scoping in things you do not control. Your cloud provider's data centers are outside your ISMS. You manage them as a supplier, under the Annex A supplier controls, not as part of your own physical estate.
The wording deserves care, since it appears on the certificate itself. See writing an ISO 27001 scope statement.
The minimum ISMS, in build order
The clauses are numbered in a sensible order, and building in roughly that order avoids rework. Each step produces something an auditor will ask to see.
Context and interested parties (4.1, 4.2). A short record of internal and external issues and of who has requirements of you: customers, regulators, investors, staff. Note which requirements the ISMS will address.
Scope (4.3). Documented, with the reasoning for any boundary.
Policy and roles (5.2, 5.3). An information security policy approved by top management, and named people responsible for the ISMS and for reporting on its performance.
Risk assessment method and first assessment (6.1.2, 8.2). Criteria for acceptance and for performing assessments, applied so repeated assessments give consistent, valid, and comparable results.
Risk treatment and the Statement of Applicability (6.1.3, 8.3). The controls you need, compared against Annex A, with a justification for each inclusion and exclusion. The detail is in how to write a Statement of Applicability.
Objectives (6.2). A few measurable information security objectives, with owners and dates.
Competence and awareness (7.2, 7.3). Evidence that people in ISMS roles are competent, and that everyone knows the policy and their part in it.
Operate and measure (8.1, 9.1). Run the controls and record the results of whatever you decided to monitor.
Internal audit (9.2). At least one audit covering the ISMS requirements and your controls.
Management review (9.3). Top management reviews the inputs the standard lists and records decisions.
Corrective action (10.2). Every nonconformity from the internal audit handled through to a cause and a fix.
Certification bodies expect to see the internal audit and the management review completed before stage 2. That is the real gating item on your timeline: not writing documents, but giving the system enough time to run and leave records.
Where small teams lose time
The same few problems recur, and none of them is about technology.
Policies describing processes that do not exist. A template access control policy promising monthly reviews creates a nonconformity the first month you miss one. Write the policy to match what you will actually do, then do it.
An internal auditor who audits their own work. Clause 9.2.2 requires you to select auditors and conduct audits so that objectivity and impartiality are ensured. In a small company the person who built the ISMS cannot credibly audit it. Common answers are an external internal auditor, or a competent colleague auditing areas they do not run.
A risk assessment done once, in a spreadsheet, and never touched. Clause 8.2 requires assessments at planned intervals and when significant changes occur. A new product line, a new region, or a new subprocessor is a significant change.
Top management in name only. Clause 5.1 puts specific duties on top management. In a startup that is usually the founders. The auditor will often want to speak to one of them, and the management review minutes should show real decisions rather than a slide that was presented and filed.
Evidence that cannot be reproduced. If the proof that a control operated is a screenshot taken the night before stage 2, the auditor will ask what happened the other 11 months. Records captured when the control ran are worth far more.
What the standard does not ask of you
Startups often overbuild because they assume requirements that are not there. ISO 27001 does not require:
A full-time security officer or a dedicated compliance team
Any particular tool, product category, or vendor
A separate written procedure for every Annex A control
Every Annex A control, if your risk assessment and context justify leaving one out
Physical security controls for premises you do not have, though remote work and laptops bring several physical controls back into scope
What it does ask is that every choice is deliberate, recorded, and consistent with your risk assessment. "We decided not to, for this reason, and the risk owner accepted the residual risk" is a complete answer. "We had not thought about it" is not.
Sequencing with a buyer waiting
Say a 25-person SaaS company has a large prospect who wants a certificate before contract renewal. A realistic plan treats the work in three phases:
Build. Scope, policy, risk assessment, Statement of Applicability, and closing the control gaps the assessment found.
Operate. Run the controls long enough to produce records, then complete the internal audit and management review.
Certify. Stage 1 reviews your documentation and readiness; stage 2 tests whether the ISMS is implemented and effective. The differences are covered in ISO 27001 stage 1 vs stage 2 audits.
Book the certification body early. Their scheduling is often the longest wait in the plan, and an agreed stage 1 date gives the build phase a deadline that everyone respects.
Tell the prospect where you are honestly. A dated plan, a scoped Statement of Applicability, and a booked stage 1 audit are often enough to keep a deal moving while the certificate is pending.
How TrustLynce helps
TrustLynce maps your controls to ISO 27001 and other frameworks, and keeps the Statement of Applicability in step with your risk register. Evidence is collected on a schedule from your cloud, identity, HR, and code systems, so records exist from the day a control starts operating rather than the week before stage 2.