ISO/IEC 27001:2022 for Developers: A Management System, Not a Checklist

By Sergey Nosov

16 October 2026

If your company holds an ISO/IEC 27001 certificate, or is working toward one, the standard reaches you as requests. Write down the secure coding rules. Keep production data out of the test environment. Show who approved that change. Explain why the build server can read every repository. The requests often arrive with a control number attached, such as 8.28, and with the impression that the standard is a list of ninety-three controls to tick off.

That impression misreads the standard. ISO/IEC 27001 specifies a management system: how an organization sets the scope of its security work, assesses risk, chooses controls, checks that they work, and improves them. Its requirements live in clauses 4 to 10, and every one of them applies. The ninety-three controls sit in Annex A, a reference list that the organization compares its own choices against. What it chose, and why, goes into a document called the Statement of Applicability.

Two consequences follow for developers. First, the controls that touch your work are the ones your organization selected and wrote into its own rules. An auditor checks that the selection follows from the risk assessment and that practice matches the rules. Second, a certificate describes a management system within a stated scope. It is not a statement about your product, and it does not stand in for HIPAA, PCI DSS, or FedRAMP.

What the Standard Requires

The full title is ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection—Information security management systems—Requirements. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) publish it jointly, which is why the official abbreviation is ISO/IEC 27001. The third edition appeared on 25 October 2022 and runs to nineteen pages.

The introduction states the purpose: an information security management system, or ISMS, “preserves the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed.” The requirements fill clauses 4 to 10 and follow a structure shared with other ISO management system standards:

Clause 4, context: the issues and interested parties that matter, and the scope of the ISMS.
Clause 5, leadership: top management’s commitment, the security policy, and roles.
Clause 6, planning: risk assessment, risk treatment, security objectives, and the planning of changes.
Clause 7, support: resources, competence, awareness, communication, and documented information.
Clause 8, operation: carrying out the plans, the risk assessments, and the treatments.
Clause 9, performance evaluation: monitoring, internal audit, and management review.
Clause 10, improvement: continual improvement, nonconformities, and corrective action.

The scope clause rules out picking among them: “Excluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document.”

Annex A and the Statement of Applicability

Annex A lists ninety-three controls, each with a title and a statement of what it requires. They fall into four themes: thirty-seven organizational, eight people, fourteen physical, and thirty-four technological controls. The numbers follow the themes, from 5.1 to 8.34, so control 8.28 is the twenty-eighth technological control. Many documents prefix an A for Annex A, as in A.8.28. This article drops the A; a bare number such as 6.3 is always a control, never a clause.

The controls enter the requirements through clause 6.1.3, on risk treatment. The organization first determines the controls its risk treatment needs, from any source, and then compares them with Annex A. The International Accreditation Forum (IAF) explained why in IAF MD 26, its transition document for the 2022 edition. The comparison, it said, lets the organization “confirm that any necessary information security control from the reference set in Annex A of ISO/IEC 27001:2022 is not inadvertently omitted.” If the comparison finds a gap, the risk treatment plan changes.

The result is the Statement of Applicability, required by clause 6.1.3 d). It lists the necessary controls, the justification for including each, and whether each is implemented. It also gives the justification for excluding any Annex A control, so it accounts for all ninety-three. Two hypothetical entries, the first with an optional evidence line, might read:

8.28 Secure coding
  Applicable: yes
  Why: risk assessment; customer
    contracts
  Implemented: yes
  Evidence: secure coding
    standard; CI checks;
    pull request reviews

8.30 Outsourced development
  Applicable: no
  Why: no supplier or contractor
    writes code for us;
    revisit before engaging one

ISO/IEC 27002:2022, published on 15 February 2022, is the companion that explains each control. Its scope clause says it “provides a reference set of generic information security controls including implementation guidance,” and ISO adds that it “cannot be certified to.” Each control carries five attributes, which let a team sort the list into views of its own. One attribute says whether a control is preventive, detective, or corrective; another names the operational capability it serves, such as application security. SGS, a certification body, points out that “using the attributes is not mandatory.”

What Changed in 2022

The 2013 edition had 114 controls in fourteen clauses; the 2022 edition has 93 controls in four themes. IAF MD 26 counts 11 new controls, 24 merged from older ones, and 58 updated. The new ones fall into three of the four themes:

Organizational: threat intelligence (5.7), information security for use of cloud services (5.23), and ICT readiness for business continuity (5.30).
Physical: physical security monitoring (7.4).
Technological: 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). All but web filtering reach development work.

The clauses changed less. A new clause 6.3 requires that changes to the ISMS itself be carried out in a planned manner; changes to systems and software remain the business of control 8.32. A one-page amendment in February 2024 added two statements on climate change to clauses 4.1 and 4.2. The IAF and ISO said the overall intent of those clauses is unchanged. As of October 2026, ISO lists the 2022 edition, with that amendment, as current.

Certified organizations had until 31 October 2025 to move to the new edition. IAF MD 26 says all certifications to the 2013 edition “shall expire or be withdrawn at the end of the transition period.” An accredited certificate today therefore names the 2022 edition.

Who Issues a Certificate, and What It Says

ISO’s help center states that “ISO itself does not perform certifications or accredit certification bodies.” Certification bodies audit organizations and issue certificates. National accreditation bodies, such as UKAS in the United Kingdom, accredit them against ISO/IEC 17021-1 and ISO/IEC 27006-1, the general and the ISMS-specific standards for such bodies. The IAF long ran the arrangement under which accreditation bodies recognize each other’s work. It ceased operations on 1 January 2026, and the Global Accreditation Cooperation Incorporated took over that role.

A certification cycle typically runs three years. Bureau Veritas, a certification body, describes the steps: a stage 1 audit assesses readiness, and a stage 2 audit reviews the management system. After certification, it says, “surveillance audits shall be conducted at least once a calendar year, except in recertification years,” and a recertification audit follows every three years.

The ISO/IEC subcommittee that writes the standard devoted the first 2026 issue of its journal to certification. Edward Humphreys, convener of the working group that maintains the ISO/IEC 27000 series, writes there that certification shows the ISMS conforms to the standard and “is effectively implemented and maintained.” Another article, on Mexico, gives the 2024 ISO Survey figures: 96,709 accredited certificates worldwide, with 4,260 in the United States. Its author infers that part of the jump from 47,291 a year earlier reflects more complete data collection, not only growth.

Reading a Supplier’s Certificate

Developers also read other companies’ certificates when a team evaluates a vendor or a cloud service. A certificate states a conclusion and a scope. Unlike a SOC 2 Type 2 report, which SOC 2 for Developers describes, it does not list the auditor’s tests and their results. Four checks are worth the time:

Accreditation and status. Look the certificate up in IAF CertSearch, which ISO says includes “only accredited certificates” and shows their status, or ask the certification body. A missing entry proves little. Two authors from the certification body DEKRA report in the journal that Germany’s accreditation body announced in November 2024 that it was not enforcing the upload rule. An unaccredited certification body has no accreditation body to vouch for its competence.
Edition. It should say ISO/IEC 27001:2022. ISO asks that a certification claim cite the standard in full, as in “certified to ISO/IEC 27001:2022,” not just “certified to ISO 27001.”
Scope. Check that the scope statement covers the service you will use.
Statement of Applicability. Ask for it; a supplier may share it under a nondisclosure agreement. The DEKRA authors advise: “As a customer you always need to examine the scope of the certificate presented as well as the statement of applicability to be sure your specific requirements are covered.”

A certificate covers a management system, not a product’s code. Erin Casteel, a certification auditor, writes in the journal: “Certification audits are based on sampling. They are focused on effectiveness of controls, but do not include penetration tests or red-team exercises.”

The Controls That Reach Developers

Most of Annex A concerns the organization as a whole: policies, roles, suppliers, people, and premises. A smaller set reaches code, pipelines, and data. Below, those controls are grouped by the work they touch. The standard states what each control must achieve and leaves the how to the organization, and ISO/IEC 27002 adds guidance. The practices are my recommendations, not text from either standard.

Building Software: 8.25 to 8.33

The standard’s introduction asks that information security be “considered in the design of processes, information systems, and controls,” and the development controls turn that into practice. They run from 8.25 Secure development life cycle to 8.33 Test information. Between them come 8.26 Application security requirements, 8.27 Secure system architecture and engineering principles, 8.28 Secure coding, and 8.29 Security testing in development and acceptance. Then come 8.30 Outsourced development, 8.31 Separation of development, test and production environments, and 8.32 Change management.

Write the rules down, then automate them. Keep the secure development rules short enough to follow, and let the pipeline enforce what it can: required reviews, required checks, and protected branches.
Put security requirements where the other requirements live: in the ticket, the specification, or the acceptance criteria. Threat modeling is a structured way to find them, as Threat Modeling with STRIDE shows.
Review code against your secure coding standard. No title in this group names code review. Still, a recorded review by someone who knows that standard is strong evidence that it is applied. The Anatomy of a Good Code Review describes what a useful review looks like.
Test for security before acceptance: static analysis, dependency checks, and dynamic tests against a deployed test environment.
Hold outsiders to the same rules. Contractors and vendors who write code for you belong in your life cycle, with its reviews and tests written into the agreement.
Keep environments apart. Use separate credentials for development, test, and production, and do not give developers standing write access to production. Protect test data as its content requires, and prefer masked or synthetic data to raw copies of production.

Secure Coding Rules Worth Writing Down

For control 8.28, start with a secure coding standard that people actually use. These six rules make a reasonable core:

Validate input at every trust boundary, against a definition of what is acceptable. The Boundary Defense Principle covers where to check and how.
Keep data out of the code that interprets it. Use parameterized queries for SQL, argument arrays with no shell for processes, and context-aware output encoding for HTML. Output encoding is the main defense against cross-site scripting. It does not stop SQL injection; parameters do.
Keep secrets out of source code and out of configuration files in version control. Load them from a vault at run time, or inject them as environment variables, which can reach child processes and debugging tools.
Scan dependencies and container images, and fix or formally accept each finding within the times your policy sets.
Log security events, not secrets. Keep credentials and unnecessary personal data out of the logs.
Fail securely. Deny on error, and keep stack traces and system details out of error messages.

My Software Development Principles series has entries on secrets management and failing securely, with their trade-offs.

Code, Configuration, and Vulnerabilities: 8.4, 8.8, and 8.9

Control 8.4 Access to source code covers read and write access to source code, development tools, and software libraries. In practice, that means repositories, build tools, and package feeds. A build agent that can read and write every repository is a privileged identity and deserves the same review as an administrator.

Control 8.8 Management of technical vulnerabilities reaches developers mostly through dependencies and base images. Set remediation times in your policy according to risk, and meet them. For control 8.9 Configuration management, infrastructure as code, kept in version control and checked for drift, is the natural evidence.

Data: 5.12, 8.10 to 8.12, and 8.24

Control 5.12 Classification of information is organizational; the technological controls are 8.10 Information deletion, 8.11 Data masking, 8.12 Data leakage prevention, and 8.24 Use of cryptography.

Make deletion a feature. Delete data when its retention period ends, and be able to show that it is gone.
Mask what leaves production. Decide which fields test environments, support tools, and analysts see in clear text, and mask or synthesize the rest.
Look for leaks in your own features: exports, bulk downloads, debug endpoints, and logs.
Use vetted cryptography and your platform’s key management; never invent a scheme. Secure Random Number Generation explains why cryptographic uses need a cryptographically secure generator.

Identity and Access: 5.15 to 5.18, 8.2, 8.3, and 8.5

Four organizational controls set the rules: 5.15 Access control, 5.16 Identity management, 5.17 Authentication information, and 5.18 Access rights. Three technological controls carry them into systems: 8.2 Privileged access rights, 8.3 Information access restriction, and 8.5 Secure authentication. The sign-in mechanism falls under 8.5, and the passwords and keys themselves under 5.17.

Give every service account, deploy key, and token an owner, a purpose, and a review date, and prefer short-lived tokens.
Grant elevated access for a task and let it expire.
Enforce authorization in the service, not only in the user interface.
Use the identity provider’s multifactor authentication and standard protocols rather than custom sign-in code.

Control 5.3 Segregation of duties applies here too: the author of a change should not be its only approver.

Logging, Cloud, Threats, and Training

8.15 Logging and 8.16 Monitoring activities. Emit security events from application code, such as sign-ins, permission changes, and exports. Protect the logs, and route alerts to someone who acts on them.
5.23 Information security for use of cloud services. The control calls for processes to acquire, use, manage, and leave cloud services. A managed database or a queue that a team adopts is one.
5.7 Threat intelligence. Feed what the organization learns about threats into design reviews and tests.
5.8 Information security in project management. Security belongs in every project, including the ones that build software.
6.3 Information security awareness, education and training. Developers need training for their role, and the organization needs records that they completed it.

Evidence, Audits, and Corrective Action

An auditor does not hold your code to the guidance in ISO/IEC 27002 line by line. The audit covers clauses 4 to 10 and checks the Statement of Applicability: whether its decisions are justified and the selected controls implemented and effective. The standard’s introduction says it “can be used by internal and external parties to assess the organization’s ability to meet the organization’s own information security requirements.” Assessing that ability takes evidence. IAF MD 26 told certification bodies that transition audits to the 2022 edition must not rely on document review alone, “especially for reviewing the technological information security controls.”

A team’s everyday work already leaves evidence for the controls that reach developers:

the secure development and secure coding documents, with their version history;
tickets and specifications that carry security requirements, and the threat models behind them;
pull requests with their reviews and passing checks;
test and scan results, with the decisions taken on each finding;
infrastructure code and configuration baselines;
access reviews for repositories, pipelines, and production;
training records, incident records, and the follow-up tickets.

A SOC 2 examination draws on these kinds of records too, so one set of habits can serve both.

The management system also checks itself. Clause 9 requires internal audits and management reviews. Clause 10 requires the organization to respond to nonconformities, evaluate whether their causes need action, and review whether the action worked. Records must show what went wrong, what was done, and with what result. That cycle of checking and correcting is how the management system gets better. A finding from an internal audit or a penetration test is input to that cycle, not a verdict on the team. I treat security findings as opportunities to improve, not as failures.

Improvement can stall when an ISMS exists only for the certificate. Certification should show that the ISMS works; some audits stop short of that. Two practitioners writing in the journal about Italy describe audits there as “more focused on formal requirements and not on the effective and efficient implementation of the information security.” The evidence that matters most comes from working systems, not from documents written for the audit.

What a Certificate Does Not Replace

ISO/IEC 27001 overlaps with many frameworks that US companies face, and it is easy to read the overlap as a substitute. Mapping tables show where controls address similar topics. NIST publishes a crosswalk between SP 800-53 Revision 5 and ISO/IEC 27001:2022. It warns that organizations “should not assume security requirement and control equivalency based solely on the mapping tables,” because mappings “are not always one-to-one and may not be completely equivalent.”

Here is what the primary sources say about four frameworks:

HIPAA. An FAQ from the Department of Health and Human Services (HHS) says that nothing in the Security Rule requires a covered entity to certify compliance. The rule does require a periodic evaluation, done internally or by an outside organization. HHS does not endorse or recognize private certifications regarding the Security Rule, and such certifications “do not absolve covered entities of their legal obligations under the Security Rule.”
PCI DSS. A PCI Security Standards Council FAQ, dated July 2012 and still posted, describes the ISO standards as a framework for an information security program. PCI DSS, it says, “provides a baseline of technical and operational requirements for the protection of payment card data.” It calls work done to implement an ISO standard “a good start to becoming PCI DSS compliant.”
FedRAMP. Under the FedRAMP rules for 2026, a provider seeking a Class A certification must have completed a certification or equivalent process under another framework within the past twelve months. Three frameworks qualify: FedRAMP Rev5, SOC 2 Type 2, and GovRAMP. ISO/IEC 27001 is not among them, and FedRAMP says providers entering the federal market should usually start with Class A.
CMMC. The Department of Defense’s 2024 rule for the Cybersecurity Maturity Model Certification program says Level 2 security requirements “are identical to the requirements in NIST SP 800-171 R2.” For cloud services that handle controlled unclassified information, the department “considered acceptance of the ISO/IEC 27001 certification” but chose the NIST-based FedRAMP Moderate baseline.

None of this makes ISO/IEC 27001 less useful. One risk assessment, one set of controls, and one evidence trail can feed several assessments. Each framework still has its own requirements and its own way of judging them.

Privacy has a separate management system standard. ISO/IEC 27701 began in 2019 as an extension to ISO/IEC 27001 and ISO/IEC 27002; ISO says its October 2025 edition can be used alone.

Checklist

Check that your system is inside the ISMS scope, then read the Statement of Applicability and find the controls that cover your work.
Write the secure development and secure coding rules down, keep them short, and let the pipeline enforce what it can.
Put security requirements in tickets and specifications, keep environments and credentials apart, and prefer masked or synthetic test data.
Treat build agents, service accounts, and tokens as identities with owners, purposes, and review dates.
Keep the evidence your work already produces, and track every finding to a recorded fix or decision.
Before relying on a supplier’s certificate, check its status, accreditation, edition, and scope, and ask for the Statement of Applicability.
Do not offer the certificate as proof for HIPAA, PCI DSS, FedRAMP, or CMMC; each has its own requirements.