ISO 27001: Requirements, Annex A Controls and Certification Guide

ISO 27001 (formally ISO/IEC 27001) is the international standard that defines how to build, run and improve an information security management system, or ISMS. It does not tell you which firewall to buy. It tells you how to find your information security risks, decide what to do about them, prove that the chosen controls work and keep improving, with top management accountable for the result.

The current edition is ISO/IEC 27001:2022, amended in 2024 to add climate change as an issue to consider. It is voluntary: no general law requires it. But for software companies, SaaS providers and IT service firms it has become one of the most common requests in customer due diligence, and an accredited certificate answers a large share of security questionnaires in one line. This guide covers the clauses, the 93 Annex A controls, the documents an auditor will ask for, the certification audits, and the mistakes we see IT teams make.

What is ISO/IEC 27001?

ISO/IEC 27001 is a requirements standard published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Its full title is "Information security, cybersecurity and privacy protection: Information security management systems: Requirements". Because it contains requirements (the word "shall"), an organisation can be audited against it and certified.

The standard has two parts that work together:

• Clauses 4 to 10 describe the management system: context and scope, leadership, planning, support, operation, performance evaluation and improvement. Every one of these clauses is mandatory for certification.
• Annex A lists 93 information security controls grouped into four themes. They are a reference set. You compare your risk treatment against them, decide which ones apply, and justify any you exclude in a document called the Statement of Applicability.

An ISMS protects three properties of information: confidentiality (only the right people can see it), integrity (it is accurate and complete) and availability (it is there when needed). The 2022 title adds cybersecurity and privacy protection to signal that the family of standards covers both, but ISO/IEC 27001 remains an information security standard. Privacy management has its own standard, ISO/IEC 27701.

History and why ISO 27001 was introduced

The standard grew out of British Standard BS 7799, first published in the 1990s as a code of practice for information security management. Its second part, which described a management system that could be certified, was adopted internationally as ISO/IEC 27001 in 2005. A major revision followed in 2013, which aligned the clauses with the common structure ISO uses for all management system standards. The 2022 edition kept those clauses with small changes and reorganised Annex A to match the 2022 edition of ISO/IEC 27002. In February 2024, ISO published Amendment 1, which adds climate action to the issues an organisation considers when it sets its context, as it did for all its management system standards.

The reason for its existence has not changed. Organisations needed a common, auditable way to show that they take information security seriously, instead of answering hundreds of different questionnaires with no independent check. A management-system approach was chosen over a fixed checklist because threats, technology and business models change. A risk-based system adapts; a checklist ages.

Organisations certified to the 2013 edition had a transition period set by the International Accreditation Forum (IAF), which ended on 31 October 2025. Any certificate issued or renewed today should reference ISO/IEC 27001:2022.

Who needs ISO 27001?

Nobody needs it by law in most countries. Organisations get certified because their customers, partners or regulators ask for evidence of good security practice. In IT and technology, those requests come most often to:

• SaaS and cloud companies whose customers store business data on their platform.
• Software development and IT outsourcing firms that get access to client systems, source code or data.
• Managed service providers, data centres and hosting companies.
• Payment, health-tech, HR-tech and ed-tech vendors handling sensitive personal data.
• Suppliers bidding for government and large enterprise contracts that list ISO/IEC 27001 as a qualification.

Geography and jurisdiction

ISO/IEC 27001 has no jurisdiction of its own. It is adopted as a national standard in many countries (for example as IS/ISO/IEC 27001 in India and as BS EN ISO/IEC 27001 in the UK) and certificates are issued by bodies accredited by national accreditation bodies that are members of the International Accreditation Forum, so a certificate from one country is recognised in the others.

A few legal frameworks refer to it directly. In India, rule 8 of the 2011 SPDI Rules under the IT Act, 2000 names IS/ISO/IEC 27001 as one standard that satisfies the requirement for reasonable security practices, provided the implementation is audited at least once a year by an auditor approved by the government. Those rules sit under section 43A of the IT Act, which the DPDP Act removes once the relevant provisions come into force, so check the current position in those guides. Other regulators, including many financial supervisors, accept it as evidence without requiring it.

A quick test: should you pursue it?

• Do customers or tenders ask for ISO/IEC 27001 by name? Then yes.
• Do your customers mainly ask for a SOC 2 report? Start with SOC 2 and design your controls so that ISO/IEC 27001 can follow.
• Are you a small team with no customer demand yet? Use the standard as a guide and start with a lighter baseline such as the CIS Controls; certify when a deal needs it.

Key requirements: clauses 4 to 10

The clauses below are mandatory for certification. Clauses 1 to 3 cover scope, references and terms and contain no requirements.

Clause 4: Context of the organisation

You identify the internal and external issues that affect your ability to achieve the purpose of the ISMS (4.1), the interested parties and their requirements, including which of those requirements the ISMS will address (4.2), and you define and document the scope (4.3). Since Amendment 1:2024, clause 4.1 also asks you to determine whether climate change is a relevant issue. Scope is the most important decision in the project: which products, locations, teams and systems are in, and how they connect to what is out.

Clause 5: Leadership

Top management must show commitment (5.1), set an information security policy (5.2) and assign roles, responsibilities and authorities (5.3). Auditors check this by interviewing leaders, not by reading a signed policy alone.

Clause 6: Planning

This is the risk engine of the standard. You define and apply an information security risk assessment process (6.1.2) with criteria for accepting risk, identify risks to confidentiality, integrity and availability, assign owners, and analyse and evaluate them. You then define a risk treatment process (6.1.3): choose treatment options, determine the controls needed, compare them with Annex A, produce a Statement of Applicability, write a risk treatment plan and get risk owners to approve it and accept residual risk. You also set measurable information security objectives (6.2). The 2022 edition added clause 6.3, which requires changes to the ISMS to be planned.

Clause 7: Support

Resources (7.1), competence with evidence (7.2), awareness (7.3), communication (7.4) and control of documented information (7.5): versioning, approval, access and retention of the documents and records the ISMS needs.

Clause 8: Operation

You plan and control the processes needed to meet the requirements (8.1), including externally provided processes such as cloud hosting, perform risk assessments at planned intervals or when significant changes happen (8.2), and implement the risk treatment plan (8.3).

Clause 9: Performance evaluation

You decide what to monitor and measure and how (9.1), run an internal audit programme (9.2) and hold management reviews with defined inputs and outputs (9.3).

Clause 10: Improvement

You continually improve the ISMS (10.1) and handle nonconformities with corrective action that addresses root causes (10.2).

Annex A controls explained

Annex A of the 2022 edition lists 93 controls in four themes. Each control is one or two sentences; the implementation guidance sits in ISO/IEC 27002.

Theme	Controls	Examples
5 Organisational	37	Policies, roles, threat intelligence, asset inventory, access control, supplier security, information security for use of cloud services, incident management, ICT readiness for business continuity, legal requirements
6 People	8	Screening, terms of employment, awareness and training, disciplinary process, remote working, reporting security events
7 Physical	14	Physical perimeters and entry, physical security monitoring, clear desk and screen, equipment siting, secure disposal
8 Technological	34	Endpoint devices, privileged access, authentication, malware protection, vulnerability management, configuration management, backups, logging and monitoring, network security, cryptography, secure development life cycle, secure coding, security testing, change management

The 2022 edition introduced 11 controls that did not exist in 2013: threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23) and secure coding (8.28). For software companies, 8.25 to 8.34 are the heart of the matter: secure development life cycle, application security requirements, secure architecture, secure coding, security testing, outsourced development, separation of environments, change management and protection of test data.

The Statement of Applicability

The Statement of Applicability (SoA) lists every Annex A control, says whether it is applied, why it is included or excluded, and whether it is implemented. Auditors read it first and test against it. Excluding a control is allowed when your risk assessment shows it is not needed (a fully remote company with no offices may justify excluding some physical controls), but each exclusion must be reasoned. You can also add controls that are not in Annex A when your risks call for them.

How to implement ISO 27001 step by step

1. Get a sponsor and a decision. Agree with leadership why you are doing it (which customers, which deadline) and who owns the ISMS day to day.
2. Define the scope. List the products, services, locations, teams, cloud accounts and suppliers in scope, and the interfaces with anything outside it. A SaaS company often scopes "the development, operation and support of product X".
3. Understand context and interested parties. Record the issues (4.1) and the requirements of customers, regulators and partners (4.2), including laws such as the GDPR or the DPDP Act that apply to your data.
4. Write the policy and assign roles. A short information security policy approved by top management, and named owners for risk, assets and controls.
5. Build an asset inventory. Information, systems, cloud services, repositories, endpoints and the people who own them. In cloud-first companies, this comes from your cloud accounts, identity provider, device management and code hosting.
6. Run the risk assessment. Use a documented method (for example likelihood and impact on a defined scale). ISO/IEC 27005 gives guidance. Record risks, owners and ratings.
7. Decide risk treatment. For each risk above your acceptance level, choose controls, compare with Annex A, write the SoA and the risk treatment plan, and get risk owners to accept residual risk in writing.
8. Implement the controls. Most work happens here: single sign-on and multi-factor authentication, joiner-mover-leaver process, device management, logging, vulnerability scanning, backups and restore tests, secure development and code review, supplier reviews, incident response.
9. Train people. Security awareness for everyone and role-specific training for developers and administrators, with records.
10. Operate and collect evidence. Run the controls for long enough to produce records: access reviews, change tickets, scan results, incident logs. Certification auditors need to see the system working, not just designed.
11. Measure. Track the objectives and metrics you set in 6.2 and 9.1.
12. Run an internal audit. Cover all clauses and the applicable controls, by someone independent of the work being audited.
13. Hold a management review. Cover the inputs listed in 9.3 and record decisions.
14. Fix nonconformities. Root cause, correction and corrective action for everything the internal audit found.
15. Choose a certification body and book the audits. Stage 1 and Stage 2, described below.

Documentation and policies required

ISO/IEC 27001 requires "documented information" in specific places. The list below follows the clauses of the 2022 edition. Anything else is documented when you decide it is needed for the ISMS to work (7.5.1 b).

Document or record	Clause
Scope of the ISMS	4.3
Information security policy	5.2
Information security risk assessment process	6.1.2
Information security risk treatment process	6.1.3
Statement of Applicability	6.1.3 d
Information security objectives	6.2
Evidence of competence	7.2
Documented information needed for operational planning and control	8.1
Results of risk assessments	8.2
Results of risk treatment	8.3
Monitoring and measurement results	9.1
Internal audit programme and results	9.2
Management review results	9.3
Nonconformities, actions taken and results of corrective action	10.2

Annex A controls add documents in practice. Control 5.1 expects topic-specific policies, and controls such as 5.37 (documented operating procedures), 5.24 to 5.28 (incident management) and 8.32 (change management) are hard to evidence without written procedures. A typical IT company ends up with an access control policy, acceptable use policy, asset management, cryptography, secure development, supplier security, incident response, business continuity, backup, logging and monitoring, and HR security procedures. Keep them short and true to what you actually do: an auditor tests whether practice matches the document.

Audits and the certification process

Certification is done by a certification body, not by ISO. Choose one that is accredited for ISO/IEC 27001 by a national accreditation body that is a signatory to the international multilateral recognition arrangement (for example NABCB in India, UKAS in the UK or ANAB in the US). That arrangement was run by the International Accreditation Forum until the end of 2025; since 1 January 2026 the IAF and ILAC have been combined into the Global Accreditation Cooperation, and existing accreditations remain valid during its transition. Accredited certificates can be checked on IAF CertSearch.

1. Stage 1 audit. A review of your documentation and readiness: scope, risk assessment, SoA, policies, internal audit and management review. It often finds gaps to fix before Stage 2.
2. Stage 2 audit. The main audit. The auditors interview staff, sample records and test whether the ISMS and the applicable controls are implemented and effective.
3. Certification decision. Major nonconformities must be closed before a certificate is issued; minor ones need an accepted corrective action plan.
4. Surveillance audits. In the first and second years after certification, the body audits part of the system.
5. Recertification. Before the three-year certificate expires, a recertification audit covers the whole system again.

Audit duration is set by the certification body using the rules in ISO/IEC 27006-1, mainly based on the number of people working in scope and the complexity of the ISMS. Ask for the calculation in the quote.

Timeline and cost considerations

There is no standard duration. The main factors are the size and complexity of the scope, how many controls already exist, the number of locations and cloud environments, and how quickly people can be freed from delivery work. Two fixed constraints shape every plan: Stage 2 needs records showing the ISMS operating (including a completed internal audit and management review), and certification bodies book audits weeks in advance. In our experience, small software companies with good engineering hygiene usually plan in months rather than weeks, and larger or multi-site organisations take longer. Treat any promise of certification in a few weeks with suspicion.

Costs fall into four groups. We do not quote figures because they vary widely by country, scope and supplier:

• Certification body fees for Stage 1, Stage 2, two surveillance audits and recertification, driven by audit days.
• Internal time of the ISMS owner, engineers and managers. This is usually the largest cost.
• Tools and services: identity and device management, logging, vulnerability scanning, backups, and optionally a compliance automation platform.
• Outside help: consultants, internal auditors or penetration testers, if you use them.

Benefits and the risk of not having it

The benefits are practical. A certificate answers a large share of security questionnaires and shortens procurement. The risk assessment forces decisions about risks that were previously nobody's job. Clear ownership and records make incident response faster. And the structure is reusable: SOC 2, ISO/IEC 27701, ISO/IEC 42001 and ISO 22301 all build on the same management-system pattern.

There is no legal penalty for not being certified. The consequences are commercial and practical: lost tenders that require it, longer sales cycles, and more exposure to the incidents a managed system would have caught. Where a law requires reasonable security (the GDPR's Article 32, India's section 43A, the US FTC Safeguards Rule for financial institutions), a working ISMS is strong evidence that you took appropriate measures, though it is not a legal safe harbour on its own.

Common mistakes and challenges for IT companies

• A scope that does not match the sales pitch. Certifying a small back office while customers think the product is covered. State the scope on the certificate clearly and check it covers what your customers buy.
• Template policies nobody follows. Auditors interview developers and check tickets. A policy that says every change gets a reviewed pull request will be tested against your repository history.
• Risk assessment as a one-off spreadsheet. Clause 8.2 requires reassessment at planned intervals and on significant change: a new product, a new cloud region, an acquisition.
• Ignoring suppliers. Cloud providers, payment processors and contractors are in scope through controls 5.19 to 5.23. Keep their certificates or reports and review them.
• No evidence of restore tests. Backups are configured but never restored. Control 8.13 expects backups to be tested.
• Treating the cloud provider's certificate as yours. AWS, Azure or Google Cloud certification covers their part of the shared responsibility model, not your configuration.
• Leaving offboarding to HR alone. Accounts in code hosting, cloud consoles and SaaS tools are often missed. Tie offboarding to single sign-on where possible.
• Internal audit done by the person who built the ISMS. Clause 9.2 requires objectivity and impartiality.

Best practices, tools and technologies

Design the ISMS around how your teams already work. Store policies where engineers look (the wiki or the repository), and collect evidence from systems rather than screenshots where you can. Helpful categories of tools include:

• Identity and access: a single sign-on provider with multi-factor authentication and automated provisioning, plus periodic access reviews.
• Device management: enforced disk encryption, screen lock, updates and endpoint protection.
• Cloud security posture management and infrastructure as code with peer review, so configuration is versioned and auditable.
• Logging and monitoring: central logs with retention and alerting (control 8.15 and 8.16).
• Vulnerability management: dependency scanning, container and host scanning, and a patch policy with timelines.
• Secure development: protected branches, mandatory review, static analysis, secrets scanning and security testing in the pipeline, mapped to the OWASP Top 10.
• Compliance automation platforms that pull evidence from these systems and map it to controls. Useful, but they do not replace the risk assessment or management decisions.

The application itself often needs work before an audit: role-based access, audit trails for admin actions, encryption of sensitive fields, session management and secure handling of customer data exports. That is the part our team builds in web application development projects.

How ISO 27001 relates to other frameworks

Framework	Relationship to ISO/IEC 27001
ISO/IEC 27002	Implementation guidance for the same 93 controls. Not certifiable.
SOC 2	A US attestation report against the AICPA Trust Services Criteria. Large control overlap; different output (a report, not a certificate).
ISO/IEC 27701	Privacy information management. The 2025 edition can be certified on its own or alongside ISO/IEC 27001.
ISO/IEC 27017 and ISO/IEC 27018	Cloud security and cloud PII guidance, usually assessed as extensions of an ISO/IEC 27001 certification.
NIST CSF	A voluntary US framework of outcomes. NIST publishes mappings between the CSF and ISO/IEC 27001.
ISO 22301	Business continuity management system. Shares the same clause structure, so the two are often integrated.
ISO/IEC 42001	AI management system with the same structure. Many companies add it to an existing ISMS.

Real-world implementation examples

The large cloud providers publish their ISO/IEC 27001 certificates and scopes on their compliance pages, and customers routinely download them during vendor reviews. Reading one is instructive: the scope statement lists exactly which services and regions are covered, which is the same precision your own scope statement needs.

A common pattern in a small SaaS company (an illustrative scenario, not a client story) looks like this. The scope is one product and its supporting functions. Most Annex A controls in theme 8 are already partly in place through the cloud platform and code hosting settings; the work is to make them consistent, add access reviews, restore tests and logging retention, and write down what already happens. Physical controls shrink because there is no server room, but home working (6.7) and device controls grow. The biggest new habits are the risk register review, the internal audit and the management review, because nothing in the company did those before.

A typical Indian IT services firm faces a different shape. Delivery centres, client-dedicated networks and contractors are in scope, client contracts add their own security requirements under clause 4.2, and the CERT-In Directions add incident reporting and log retention duties that the ISMS must cover as legal requirements.

Next steps

1. Confirm the demand: list the customers or tenders that ask for ISO/IEC 27001 and the date you need it by.
2. Draft a scope statement for the product or service those customers buy.
3. Run a gap assessment of clauses 4 to 10 and the 93 Annex A controls against what exists today.
4. Plan the engineering work the gaps reveal, especially in access control, logging, backups and the secure development life cycle.
5. Pick an accredited certification body early and agree audit dates.

If the gaps are in your application rather than your paperwork, that is work we can take on. See our SaaS product development page or contact us.

Frequently asked questions

Is ISO 27001 mandatory?

No. ISO/IEC 27001 is a voluntary standard. It becomes necessary in practice when customers, tenders or partners require it, and some laws, such as India's SPDI Rules, recognise it as one way to show reasonable security practices.

What is the current version of ISO 27001?

ISO/IEC 27001:2022, amended by Amendment 1:2024, which adds climate change as an issue to consider in clauses 4.1 and 4.2. The transition period for certificates issued against the 2013 edition ended on 31 October 2025.

How many controls are in ISO 27001 Annex A?

The 2022 edition has 93 controls in four themes: 37 organisational, 8 people, 14 physical and 34 technological. The 2013 edition had 114 controls in 14 domains; many were merged rather than removed.

Do we have to implement all 93 controls?

No. You determine the controls you need from your risk assessment, compare them with Annex A and record in the Statement of Applicability which ones apply and why any are excluded.

Who issues ISO 27001 certificates?

Certification bodies, not ISO. Use one accredited by a national accreditation body that belongs to the international recognition arrangement (run by the IAF until 2025 and by the Global Accreditation Cooperation since January 2026), so that the certificate is recognised internationally and can be verified.

How long is an ISO 27001 certificate valid?

Three years, provided you pass the surveillance audits in the first and second years. A recertification audit is needed before it expires.

What is the difference between ISO 27001 and ISO 27002?

ISO/IEC 27001 contains the requirements you are certified against. ISO/IEC 27002 gives guidance on implementing the controls listed in Annex A. You cannot be certified to ISO/IEC 27002.

Is ISO 27001 or SOC 2 better for a SaaS company?

Neither is better in general. Ask your customers which they want. US enterprise buyers often expect SOC 2; buyers in Europe, Asia and the public sector often expect ISO/IEC 27001. The control work overlaps, so many companies end up with both.

Can a fully remote company get ISO 27001 certified?

Yes. Physical controls shrink and can be justified as partly not applicable, while controls on remote working, endpoint devices and cloud services carry more weight. Auditors can audit remotely where the certification body's rules allow it.

Does ISO 27001 make us GDPR compliant?

No. It supports the security obligations in GDPR Article 32, but the GDPR has many other requirements, such as lawful basis, transparency and data subject rights. ISO/IEC 27701 is closer to privacy law, though still not a substitute for it.

Can our cloud provider's certification cover us?

No. It covers the provider's services within its scope. Your configuration, your application, your people and your processes need their own controls, and your ISMS must manage the provider as a supplier.

What happens if the auditor finds a major nonconformity?

A certificate is not issued, or an existing one may be suspended, until the nonconformity is corrected and the certification body has verified the correction. Minor nonconformities need an accepted corrective action plan.