ISO 27001 certification: the complete guide for tech companies in 2026
Most tech companies come to ISO 27001 the same way: a prospective enterprise customer asks for it during procurement, a deadline appears, and suddenly a process that takes months needs to happen in weeks. If that's where you are, this guide is written for you.
ISO 27001 is the international standard for information security management. Getting certified means an accredited auditor has verified that your organisation runs a functioning Information Security Management System (ISMS) — not just that you have policies, but that you apply them, monitor them, and improve them. This guide walks the path a tech company actually takes from "we need ISO 27001" to "we have the certificate."
What certification actually involves
ISO 27001 certification is a two-stage audit process conducted by an accredited Certification Body (CB) of your choice. The CB is independent — no tool or consultant certifies you. A human auditor from an accredited body does, based on what they find in your evidence.
Stage 1 — documentation review. The auditor reads your ISMS documentation: your information security policy, scope statement, risk assessment methodology, risk register, Statement of Applicability (SoA), and treatment plan. Stage 1 is largely a desk review. Its job is to confirm that the system you've described on paper is coherent and ready for a real audit. A well-prepared organisation gets through Stage 1 in a day or two and emerges with a list of minor clarifications to address before Stage 2.
Stage 2 — implementation audit. This is the substantive audit. The auditor tests whether the controls documented in your SoA are actually implemented. They interview staff, review logs and records, inspect technical configurations, and sample evidence against specific Annex A controls. Stage 2 is where gaps that look invisible on paper become visible in practice — and where undocumented or absent evidence fails controls that were technically in scope.
Certificate and surveillance. Pass Stage 2 and you receive a three-year certificate. Surveillance audits follow annually (typically covering a subset of controls), and a full recertification audit runs at the end of the three-year cycle. The clock doesn't stop — lapsing surveillance means the certificate lapses.
Defining your scope
Scope is the single decision that most directly controls the size and difficulty of your audit. A well-defined scope is not the smallest possible scope — it's the scope that a reasonable auditor will accept as credible, given what your business actually does and what assets your customers care about.
Your scope statement must clearly describe the organisational units, physical locations, and information assets covered by the ISMS. For a typical B2B SaaS company, this usually means the production environment, the team operating it, and the data processed within it. What it doesn't automatically include: your parent entity's shared services, third-party infrastructure you don't control, or business units with no connection to the in-scope systems.
Scope that's too narrow signals gaming rather than genuine security posture. Auditors probe the edges. If your customer data flows through systems you've excluded from scope, expect that to be challenged.
The scope statement connects directly to your risk assessment (what assets are in scope), your SoA (which Annex A controls apply), and your evidence burden (what you need to demonstrate). Getting scope right early compresses work downstream. Getting it wrong means rework at every stage.
The Annex A control structure
ISO 27001:2022 Annex A contains 93 controls across four themes:
| Theme | Controls | Range |
|---|---|---|
| Organisational | 37 | A.5.1 – A.5.37 |
| People | 8 | A.6.1 – A.6.8 |
| Physical | 14 | A.7.1 – A.7.14 |
| Technological | 34 | A.8.1 – A.8.34 |
If you're working from documentation referencing 114 controls in 14 clauses, that's the superseded 2013 version. The 2022 revision restructured and consolidated the control set. Most CBs are now auditing to the 2022 standard; confirm with your CB before you begin.
Not every control applies to every organisation. Your Statement of Applicability documents which controls are included, which are excluded, and the justification for each decision. Exclusions are legitimate — a company with no removable physical media has a credible basis for excluding A.7.10 (storage media) — but exclusions must be documented and defensible.
The controls that trip up first-time SaaS companies most often are the ones that require records rather than just configurations:
- A.8.8 (management of technical vulnerabilities) — requires a systematic process and documented evidence it ran, not just a scanner you have access to.
- A.6.2 (terms and conditions of employment) — every employee in scope must have a signed agreement covering information security responsibilities.
- A.5.10 (acceptable use of information and other associated assets) — the policy needs to exist, be communicated, and there needs to be evidence of that communication.
- A.8.16 (monitoring activities) — log monitoring must be active and evidenced, not just enabled.
The 2022 revision also introduced eleven new controls. Several are particularly relevant for SaaS companies: A.5.7 (threat intelligence), A.5.23 (information security for use of cloud services), A.5.30 (ICT readiness for business continuity), A.8.9 (configuration management), and A.8.10 (information deletion). These aren't necessarily hard to implement, but they need to be in your SoA and evidenced.
What good evidence looks like
This is where most first-time audits stumble. Companies implement controls correctly but fail to document them in a form an auditor can verify. The auditor isn't there to take your word for it — they're sampling evidence to confirm that controls operate as described.
Good evidence has three properties:
It's specific to your organisation. A policy template downloaded from the internet with your logo on it is weak evidence. A policy that references your actual systems, your actual roles, and your actual data classification scheme is strong evidence. Auditors have seen every template; they're assessing whether you've internalised the content.
It shows the control operated over time. A penetration test report from last month is good evidence for A.8.8 — but it's stronger paired with a vulnerability backlog showing how findings were tracked and remediated. Logs from your SIEM showing active monitoring are good evidence for A.8.16, but only if there's a process document showing who reviews them and how often.
It matches your SoA. Every in-scope control needs corresponding evidence. If your SoA says A.5.15 (access control) is implemented and your implementation notes describe role-based access control in your production environment, your evidence needs to show that RBAC is actually configured — access review records, provisioning and deprovisioning logs, or equivalent.
The documents an auditor typically expects to sample for a SaaS company:
- Policy set — information security policy, access control policy, acceptable use policy, incident response policy, asset management policy, change management policy.
- Risk register — assessed risks, treatment decisions, residual risk acceptance.
- SoA — all 93 controls accounted for with applicability decisions and justification.
- Treatment plan — specific controls applied to specific risks, owners, timelines.
- Technical evidence — vulnerability scan results, penetration test reports, backup test records, access review records, patching logs, DR test results.
- Training records — evidence that all in-scope staff completed security awareness training.
- Incident log — records of any security events, or affirmative evidence that the process ran even when no incidents occurred.
- Internal audit records — evidence that the ISMS was internally reviewed, not just externally audited.
- Management review minutes — records of leadership reviewing ISMS performance against objectives.
The last two — internal audit and management review — are clause requirements (ISO 27001 clauses 9.2 and 9.3), not optional Annex A controls. They're also among the most commonly missed. Auditors check for them explicitly.
The realistic timeline
"Audit-ready in weeks, certified in months" is the realistic target for a well-prepared mid-size SaaS company. The audit itself has a minimum lead time set by the CB's scheduling and the gap between Stage 1 and Stage 2 (typically two to eight weeks for remediation). What varies enormously is the preparation time before you engage the CB.
A company that has existing security practice and documentation can compress preparation to six to eight weeks of focused work. A company starting from scratch — no formal policies, no risk register, no evidence backlog — should budget four to six months.
The CB's own schedule adds two to four weeks minimum. Book your auditor earlier than you think you need to; slots fill.
Where teams lose months
Scope debate. Agreement between founders, legal, and the engineering lead on what's actually in scope takes longer than expected. This should happen before anything else. It usually doesn't.
Policy authorship. Writing policies from scratch that reflect actual practice — not templates — is slower than people expect. A policy set your team actually follows takes multiple review cycles. A policy set written to satisfy a checkbox doesn't hold up when an auditor asks staff to describe it.
Evidence archaeology. Finding evidence that controls operated — not just that you have the tools — means digging through logs, pulling records, and sometimes discovering the records weren't kept. If your vulnerability management process produces findings but no remediation tracking, you have a tool, not a control.
Risk assessment methodology. Organisations often restart their risk assessment when they realise their first attempt won't satisfy the standard. The methodology — how you score likelihood and impact, what risk appetite means in practice — needs to be consistent, documented, and applied uniformly across the asset register.
Supplier management. Your SoA will include controls around supplier relationships (A.5.19–A.5.22). If you haven't previously assessed your critical suppliers against security criteria, this takes time. For a SaaS company, critical suppliers include your cloud infrastructure provider, CI/CD toolchain, monitoring stack, and any third party with access to in-scope systems.
Leaving internal audit too late. ISO 27001 clause 9.2 requires internal audits. For a first certification, this typically means a structured internal review of your ISMS before Stage 2 — documented, with findings and any corrective actions. It can be conducted by a knowledgeable internal resource as long as they're independent of the area being audited. Scheduling this six weeks before your Stage 2 date and treating it as optional is the pattern that most often delays certificates.
How scoper.io fits in
scoper.io runs the assessment side of this process. You upload your policies, configurations, and evidence; the platform interrogates each document against the relevant Annex A controls; and it produces per-control verdicts — covered, partial, gap, or N/A — with the specific evidence cited. The reasoning is shown, not asserted. When an auditor asks how you determined A.8.8 is covered, you have a traceable answer grounded in your actual documents, not a spreadsheet cell marked green.
From the assessment, scoper.io generates a gap analysis, a Statement of Applicability, and an assessor-ready dossier — the documents you walk into Stage 1 with. What it doesn't do is replace the audit, or guarantee an outcome. What it does is compress months of manual evidence gathering, spreadsheet maintenance, and consultant-led review into something you can run yourself, before a CB ever enters the picture.
If you're heading into a first audit, book a demo — we'll show you what the assessment produces against your specific environment.
Stage 1 and Stage 2 in practice
Organisations that pass Stage 1 cleanly typically share a few traits: their scope statement is unambiguous, their SoA is complete and internally consistent, and their documentation reflects what actually happens rather than what should happen.
The Stage 1 output is a list of items for clarification or improvement before Stage 2. Minor observations are normal — a missing cross-reference, an undated policy, a treatment plan item without a named owner. Major non-conformities at Stage 1 are rarer but signal that the ISMS isn't ready; they typically require a second Stage 1 before Stage 2 can proceed.
Stage 2 is evidence-intensive. Auditors sample: they won't review every record for every control, but they'll ask for representative evidence across key control areas, probe areas where Stage 1 flagged concerns, and interview the staff responsible for operating specific controls. The interview component is worth preparing for — "we have a policy for that" is not the same as being able to explain how the policy was applied last quarter.
Non-conformities at Stage 2 fall into two categories: major (the control doesn't exist or doesn't operate as required — typically requires remediation and evidence review before the certificate issues) and minor (the control operates but with an identified gap — typically addressed through a corrective action plan and verified at the first surveillance audit).
After the certificate
Certification is the beginning of an ongoing commitment. The three-year certificate cycle requires annual surveillance audits, which review a rotating subset of controls. Changes to your scope, significant incidents, or material changes to your ISMS trigger CB notification obligations.
The ISMS needs to keep running between audits: internal audits, management reviews, risk register updates, and control monitoring all need to happen on a defined schedule and be evidenced. An organisation that treats certification as a project and then stops maintaining the ISMS will fail its first surveillance audit.
Maintenance is also where the economics of the investment become clear. A well-designed ISMS compounds: the risk register captures security decisions as they happen, the evidence backlog builds continuously rather than in a pre-audit sprint, and each year's surveillance becomes progressively less stressful. Companies that bolt on compliance at audit time pay for the certificate in panic and consultant fees — every year.
The short version
ISO 27001 certification involves: defining a credible scope, conducting a documented risk assessment, writing policies that reflect actual practice, implementing controls against the 2022 Annex A control set, producing a Statement of Applicability, building an evidence backlog, conducting an internal audit and management review, and then surviving a two-stage external audit by an accredited CB.
The parts most companies underestimate are the evidence burden — especially for controls that require records over time, not just configurations — and the lead time on the CB's calendar. The parts that most compress preparation time are a well-defined scope, a systematic approach to evidence collection, and a gap analysis that shows you specifically what's covered and what isn't before the auditor does.
Book a demo at scoper.io to see what a grounded assessment looks like against your actual documents.
See it run on your own evidence.