ISO/IEC 27001

What is ISO/IEC 27001

ISO/IEC 27001 is the international standard for an information security management system (ISMS): the set of policies, roles, risk decisions, controls, and review routines an organization uses to protect its information on purpose rather than by accident. It does not prescribe a fixed list of technical settings. It requires you to understand your own risks, decide which controls address them, run those controls, check that they work, and improve them.

The standard exists because buyers cannot audit every supplier themselves. A certificate from an independent, accredited certification body lets a customer in another country, or another industry, accept that a supplier runs a real security program without repeating the audit. That is why ISO/IEC 27001 shows up in procurement questionnaires, master service agreements, and tender requirements far more often than in law.

The current edition is ISO/IEC 27001:2022, published October 25, 2022, with a one-line Amendment 1 in February 2024 that adds climate change to the context clauses. The transition from the 2013 edition ended on October 31, 2025; any certificate still citing 2013 is no longer valid.

The most common misconception: ISO does not certify anyone. ISO and IEC write the standard. Certificates come from separate commercial certification bodies, and the credibility of a certificate depends on whether that body is accredited. Two certificates can look identical and carry very different weight.

Who ISO/IEC 27001 applies to

Nothing in ISO/IEC 27001 makes it mandatory. Organizations adopt it because:

• a customer, prospect, or tender requires a current certificate, often with a specific scope;
• a regulator or sector scheme accepts it as evidence of a security program (several European regimes name it as one way to demonstrate risk management);
• leadership wants a recognized structure for a security program that is growing past one person’s head; or
• an international buyer will not accept a SOC 2 report, or a US buyer will not accept a certificate alone, and the organization needs both.

The surprise case is the small supplier. A 20-person software company that lands one enterprise customer can be asked for ISO/IEC 27001 certification as a contract condition, with a deadline. Headcount does not exempt you; it only shortens the audit.

The second surprise is scope. A certificate covers the ISMS scope written on it, not the whole company by default. A vendor can be certified for one data center or one product line and nothing else. When you are asked for a certificate, ask which parts of your business the requester expects inside the scope. When you receive one from a vendor, read the scope statement before you rely on it.

Who manages and enforces ISO/IEC 27001

Three separate groups matter, and confusing them causes most of the bad decisions people make about this standard.

ISO and IEC write it. Joint technical committee ISO/IEC JTC 1/SC 27 develops ISO/IEC 27001 and the rest of the 27000 family. The committee publishes editions and amendments; it does not audit, certify, or keep a list of certified companies. The standard itself is a paid document from the ISO store or your national standards body.

Accreditation bodies police the auditors. Each country has a national accreditation body: ANAB in the United States, UKAS in the United Kingdom, and peers elsewhere. They assess certification bodies against ISO/IEC 17021-1 and ISO/IEC 27006-1, the rules for how ISMS audits must be planned, staffed, and timed. The International Accreditation Forum (IAF) binds those bodies together so a certificate accredited in one country is recognized in another, and it sets the transition deadlines when the standard changes.

Certification bodies audit you. A certification body (CB) is a company you hire. It plans the audit, sends auditors, decides whether to certify, and issues the certificate with its own name and its accreditation mark on it.

Enforcement is commercial. No agency fines you for lacking a certificate. What happens instead is that a contract is not signed, a renewal is conditioned on certification by a date, or a security questionnaire is failed. If you hold a certificate and stop meeting the standard, the certification body can suspend or withdraw it after a surveillance audit, and the customers who relied on it will ask why.

What is in scope

The unit of scope in ISO/IEC 27001 is the ISMS scope statement: a written description of the organizational units, locations, services, systems, and information the management system covers. Clause 4.3 requires it; the certificate prints a version of it. Everything else in the standard is applied inside that boundary.

Scope spreads in predictable ways:

• People: employees and contractors who work inside the boundary, including their onboarding, training, and offboarding.
• Suppliers: cloud providers, data centers, and outsourced functions that hold or process in-scope information. You cannot certify them, but you must manage the risk they create and hold evidence that you do.
• Interfaces: where in-scope processes hand information to out-of-scope parts of your own company. Auditors look hard at those edges.
• Information itself: the standard covers information in any form, so paper, conversations, and backups count alongside systems.

A scope exercise you can run this week:

1. List the products or services the requester cares about.
2. Name the teams and locations that deliver them.
3. Inventory the systems and data stores those teams touch, including SaaS tools and logging.
4. List the suppliers that hold or process that information.
5. Draw the boundary and write, in two or three sentences, what is inside it and why anything obvious is outside.

Narrow scopes are legitimate and common, and they reduce audit days and cost. They do not reduce obligations inside the boundary, and a scope that leaves out the thing the customer actually buys will fail the customer’s review even if it passes the audit. Scope can also be widened later through an extension audit, which is cheaper than starting over.

What ISO/IEC 27001 requires

The requirements sit in two places with different weight.

Clauses 4 through 10 are mandatory for every certified organization and cannot be excluded:

4. Context of the organization: understand internal and external issues (including, since Amendment 1, climate change), interested parties, and define the ISMS scope.
5. Leadership: top management commitment, an information security policy, and assigned roles.
6. Planning: a risk assessment and risk treatment process, the Statement of Applicability, and measurable security objectives.
7. Support: resources, competence, awareness, communication, and controlled documentation.
8. Operation: actually run the risk assessment and treatment on a schedule and control what changes.
9. Performance evaluation: monitoring and measurement, an internal audit program, and management review.
10. Improvement: handle nonconformities and corrective actions, and improve continually.

Annex A is a reference list of 93 controls in four themes: organizational (37), people (8), physical (14), and technological (34). The 2022 edition consolidated the 2013 list of 114 controls and added 11 new ones, including threat intelligence, cloud services security, configuration management, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. You do not have to implement every Annex A control. You must consider each one, decide whether it applies to your risks, and record the decision and its justification in a Statement of Applicability (SoA). Excluding a control because it is inconvenient is not a justification; excluding one because the risk it treats does not exist in your scope is.

The documents that matter, and how much weight each carries:

• ISO/IEC 27001:2022 is the requirements standard. It is the only document you are certified against. Buy it and read it; it is short.
• ISO/IEC 27002:2022 is implementation guidance for each Annex A control. Auditors reference it; you are not certified against it.
• ISO/IEC 27005 is guidance on information security risk management. Useful, optional.
• ISO/IEC 27006-1:2024 governs the certification bodies: auditor competence, audit time, and what may appear on a certificate. It explains why quotes from different bodies land close together. You do not need to read it, but knowing it exists helps when a quote looks too good.
• ISO/IEC 27000 is a free overview of the family’s concepts and how the documents relate; the sixth edition was published in July 2026.

Cloud and privacy extensions: 27017, 27018, and 27701

Customers in cloud and privacy-sensitive markets sometimes ask for more than a plain 27001 certificate. Three companion documents add sector-specific controls that a certification body can include in the scope of the same ISMS audit:

• ISO/IEC 27017 adds cloud-specific controls for both cloud service providers and cloud customers. The second edition was published on July 27, 2026, aligned to the 2022 control structure; programs citing the 2015 edition should plan a gap review.
• ISO/IEC 27018 adds controls for protecting personally identifiable information (PII) in public clouds acting as PII processors. The third edition (August 2025) is aligned to ISO/IEC 27002:2022.
• ISO/IEC 27701 covers a privacy information management system (PIMS) for PII controllers and processors. The 2025 edition made it a stand-alone management system standard, so it can now be certified with or without an ISO/IEC 27001 certificate.

ISO/IEC 27017 and 27018 are guidance documents, not certification standards on their own. They appear on a 27001 certificate as additional standards in scope, add controls to your SoA, and add days to your audit. Ask the requester whether they actually need them before you add them; many do not.

How compliance is validated

ISO/IEC 27001 is validated by certification: a third-party certification body audits your ISMS and, if it conforms, issues a certificate. Nothing else counts as being “ISO 27001 certified.” Self-declared conformance, a consultant’s readiness letter, or a certificate from an unaccredited body are all different things, and buyers know it.

The certification cycle

• Stage 1 is a documentation and readiness review, often remote, over one to three audit days. The auditor checks the scope statement, risk assessment, SoA, policies, and whether the internal audit and management review have happened. Stage 1 findings tell you whether Stage 2 will go badly.
• Stage 2 is the implementation audit: interviews, evidence sampling, and control testing against your SoA, on site or remote, over several days. Nonconformities are graded major or minor; majors must be closed before the certificate is issued.
• The certificate is valid for three years, provided you pass surveillance audits at roughly twelve and twenty-four months. A recertification audit near the end of year three starts the next cycle.

A certificate is a record that the ISMS conformed, for a stated scope, at the time of audit, and that surveillance has kept it in good standing. It is not a statement that no breach can occur, and it is not permanent: withdrawn and expired certificates are common, which is why buyers verify them.

Who may perform the work

Any company can call itself a certification body and sell certificates. What separates a credible one is accreditation: a national accreditation body has assessed it against ISO/IEC 17021-1 and ISO/IEC 27006-1 and lists it as accredited for ISMS certification. Accreditation attaches to the certification body, not to individual auditors, and the body is responsible for its auditors’ competence. Accredited bodies must have moved to ISO/IEC 27006-1:2024 by March 31, 2026.

To verify a body or a certificate:

• Search IAF CertSearch, the global database that accredited bodies are required to populate, by certificate number or company name.
• Check the accreditation body’s own directory (ANAB in the US, UKAS in the UK) for the certification body and confirm ISO/IEC 27001 is in its accredited scope.
• Read the scope statement and the expiry date on the certificate itself.

Consultants, including Aeris Secure, do not certify. ISO/IEC 17021-1 forbids a body from auditing an ISMS it helped build, so the firm that writes your policies cannot be the firm that certifies them. Consultants do commonly perform the clause 9.2 internal audit, run readiness assessments, and build documentation.

The ISO/IEC 27001 certification process

A first certification usually runs six to eighteen months from decision to certificate. The steps:

1. Confirm the obligation. Find out who needs the certificate, what scope they expect, whether they require accredited certification, and by when.
2. Define the ISMS scope and get top management to sign the information security policy and assign roles (clauses 4 and 5).
3. Assess risk and select controls. Run the risk assessment, decide treatments, and write the Statement of Applicability (clause 6).
4. Implement and document. Close control gaps, write the required procedures, train people, and start generating records (clauses 7 and 8).
5. Audit yourself. Complete at least one internal audit cycle and a management review before the certification body arrives (clause 9). Auditors will not proceed to Stage 2 without them.
6. Select a certification body and pass Stage 1 and Stage 2.
7. Maintain. Close findings, run the annual cycle, and pass surveillance audits.

Who decides, and what to ask them

The party that sets your real obligation is whoever is asking for the certificate: a customer’s procurement or security team, a tender authority, or a partner. Their security questionnaire or contract clause is the request. If a sales colleague relayed the ask, get the requester’s security contact directly, because the details below rarely survive a second-hand conversation.

Ask, and keep the answers in writing:

• Do they require a certificate from an accredited certification body, and does the accreditation body matter to them?
• Which of your products, services, locations, and teams must be inside the scope for the certificate to satisfy them?
• Do they need ISO/IEC 27017, 27018, or 27701 in the scope, or is plain 27001 enough?
• Will they accept a SOC 2 report instead, or in the meantime? Will they accept a signed readiness plan with a certification date?
• What is the deadline, and is it tied to contract signature, renewal, or go-live?
• What do they want to see: the certificate only, or also the scope statement, the SoA, the latest surveillance result, or penetration test summaries?

The answers set your scope and your calendar. A requester who only cares about one hosted product may accept a scope that takes half the time and cost of a company-wide certificate.

Reality check: the paperwork is not the long part. Risk assessment, control implementation, and letting the ISMS run long enough to generate records are what consume the calendar. Certification bodies also book weeks or months out, so contact one before you are ready.

Cost, time, and internal effort

The cost range on this page covers certification body fees only, for the most common path: an initial Stage 1 and Stage 2 audit at a typical single-site organization. That definition keeps standards comparable across this site, and it is the number you can check against a quote.

Certification fees are unusually predictable because ISO/IEC 27006-1 sets the audit days from your headcount and complexity, and the body multiplies days by its day rate:

• Initial certification typically runs $8,000 to $40,000. Small scopes under 25 people can land near $5,000 to $10,000; several hundred people or multiple sites push past $40,000.
• Surveillance audits in years two and three run roughly $3,000 to $12,000 each.
• Recertification in year three costs roughly 70 to 100 percent of the initial audit.
• Day rates in 2026 run roughly $1,200 to $2,200, and have risen with auditor scarcity. Get three quotes against an identical scope brief; the day counts should match, so the difference is rate and travel.

The certificate is often the smaller cost. Outside the range above:

• readiness or implementation consulting, commonly $15,000 to $50,000 when used;
• compliance tooling or a platform subscription;
• security tools the risk assessment shows you lack, and a penetration test if your SoA promises one;
• the internal hours to build and run the ISMS, which published estimates put at several hundred to a thousand hours in the first year; and
• fixing findings and repeating parts of the audit.

The page’s cost and effort ranges are directional, not a quote. The best predictors are headcount and sites inside the scope, how much of your control environment already exists and is documented, and whether add-on standards are in scope.

Time follows the same pattern. An organization with mature controls and a narrow scope can certify in six months. A first ISMS at a company with no documented security program usually takes a year or more, most of it before the certification body is involved.

Maintaining compliance

Certification is a three-year cycle with annual checkpoints, and the standard expects the ISMS to keep running between them. A typical operating rhythm:

• at least one risk assessment review per year and after significant changes, with the SoA updated to match;
• an internal audit program that covers the whole ISMS across the cycle (clause 9.2);
• a documented management review at least annually (clause 9.3);
• control operation evidence throughout the year: access reviews, training records, supplier reviews, incident records, change records, backup tests;
• corrective actions tracked to closure, especially any minor nonconformities from the last audit, which the next auditor will check first; and
• the surveillance audit each year and recertification in year three.

The risk assessment is where most organizations struggle to show a repeatable method. The free risk assessment tool on this site produces a risk register and report in the browser without sending your data anywhere, which is enough to satisfy clause 6.1.2 for many small scopes.

Scope changes silently. A new product, office, acquisition, or major supplier can land inside or beside your boundary without anyone updating the scope statement or SoA. Hook the ISMS into change management, procurement, and hiring so those changes are reviewed before the auditor finds them. Certification bodies also require you to tell them about significant changes to the certified scope between audits.

How to get started

If ISO/IEC 27001 has just landed on your desk, begin with five concrete actions:

1. Get the requirement in writing. Ask the requester which scope, whether accreditation is required, whether they need 27017, 27018, or 27701, and the deadline.
2. Buy and read the standard. ISO/IEC 27001:2022 is a short document; clauses 4 through 10 are a few pages. Buy ISO/IEC 27002:2022 too if you will be writing the SoA yourself.
3. Draft the scope statement. Two or three sentences naming the services, teams, locations, and systems inside the boundary, using the exercise above.
4. Run a first risk assessment and gap check. Use a simple method (the risk assessment tool works) and walk the 93 Annex A controls, marking each applicable or not with a reason. That draft is your first Statement of Applicability.
5. Get three certification body quotes against the same scope brief and headcount, and ask each for its earliest Stage 1 date. Confirm each body’s accreditation in IAF CertSearch or the ANAB directory before you sign.

For official starting points, use the ISO/IEC 27001 page for the current edition and amendments, the SC 27 committee page for the wider 27000 family, and IAF CertSearch to check any certificate you are shown.

The first goal is not to implement 93 controls. It is to know who needs the certificate, for which scope, by when, and to write down the risks that scope actually faces. Once those are on paper, the rest of the ISMS is a project plan rather than a mystery.