If we build or configure software ourselves, how much secure development does ISO 27001 expect?

Start

We build or configure software and must show it is built securely

The development controls ask that security is built into how software is made, rather than tested in at the end. The Library says they apply where you develop or configure software yourself, including scripts, integrations and low-code applications. How much you need depends on what you build and the data it handles.

• Then: Do we write code, scripts, infrastructure as code or low-code apps?

Decision

Do we write code, scripts, infrastructure as code or low-code apps?

Infrastructure as code and scripts that deploy or configure services count. If the only software you use is bought and configured through a console, the development controls may not apply, though the requirements for buying still do. If you are not sure what your engineers build, answer yes.

• No: Record why development does not apply; cover bought software instead
• Yes, or not known: Does the software face the internet or handle sensitive data?

Outcome

Record why development does not apply; cover bought software instead

Write the reason in the Statement of Applicability, naming what you checked. Do not claim the control is met by default; claim only that you checked and found no development. Bought software still needs security requirements before purchase and testing before acceptance. The questions on justifying an exclusion and on the cloud services you rely on go further.

Decision

Does the software face the internet or handle sensitive data?

Depth of control should follow risk. The pack's AI review procedure sets three depths by what a feature can reach, and the same idea works here: more rigour for exposed systems and sensitive data, less for an internal script. If unsure, answer yes.

• Yes, or not known: Set security requirements for each new feature from its data and risks
• No: Keep it light: a short standard, peer review and basic scanning

Step

Keep it light: a short standard, peer review and basic scanning

For low-exposure software write a one-page standard with the few rules you will enforce: peer review before merge, dependency scanning and no secrets in code. Say in the Statement of Applicability that the control is applied in this proportion.

• Then: Is peer review before merge enforced by the tooling?

Step

Set security requirements for each new feature from its data and risks

For a new application or major change write down what it needs: authentication, access control, logging and data protection. Put them in specifications and acceptance criteria. Requirements added after the contract is signed are the Library's named mistake.

• Then: Write a short secure development standard and design principles

Step

Write a short secure development standard and design principles

Put in one short standard the design principles (least privilege, defence in depth, secure defaults), the coding rules for your languages and how developers are trained in them. Review the design of significant systems against it before building. Principles written but never applied to a design is the Library's named mistake.

• Then: Is peer review before merge enforced by the tooling?

Decision

Is peer review before merge enforced by the tooling?

A rule that depends on goodwill fails under deadline pressure. Branch protection that blocks a merge without a second reviewer is a record that cannot be skipped quietly. If a developer can merge their own code, answer no.

• Yes: Do code and dependency scans run, with someone triaging findings?
• No, or not known: Turn on required review and protected branches

Step

Turn on required review and protected branches

Set the repository so a change needs a reviewer other than its author, and so the pipeline must pass before release. Record any bypass with its reason, and review those records.

• Then: Do code and dependency scans run, with someone triaging findings?

Decision

Do code and dependency scans run, with someone triaging findings?

Scanning tools whose findings nobody triages are the Library's named mistake. Vulnerable dependencies left for months are the other. If scans run but nobody owns the results, answer no.

• Yes: Are environments separate, with no standing production rights?
• No, or not known: Add the scans to the pipeline and name who triages and by when

Step

Add the scans to the pipeline and name who triages and by when

Choose scans for the languages and components you use, run them on every change, and set a deadline for each severity. The vulnerability pack's prioritisation can set the deadlines. Record exceptions as you would for any other finding.

• Then: Are environments separate, with no standing production rights?

Decision

Are environments separate, with no standing production rights?

Developers with permanent administrator rights in production and tests run against live data are the Library's named mistakes. Separate accounts, separate credentials and a controlled route to production fix them. If developers can change production directly, answer no.

• Yes: Test before release; add an independent test for significant releases
• No, or not known: Separate the environments; move changes only by the release route

Step

Separate the environments; move changes only by the release route

Use separate accounts or subscriptions, give developers time-limited production access through a request, and keep live data out of test. Link the release route to your change procedure. Where live data is essential in test, get approval, protect it to the same level and delete it afterwards.

• Then: Test before release; add an independent test for significant releases

Step

Test before release; add an independent test for significant releases

Run security tests in the pipeline. For significant releases, or at least every 12 months for exposed systems, add a penetration test (the Library's 12-month example), by someone who did not build the system where you can (the flow's advice; the pack's AI review requires it only at its deepest level). The pack's AI review procedure likewise puts an independent tester at its deepest level.

• Then: Are test findings tracked to closure, with a date and an owner?

Decision

Are test findings tracked to closure, with a date and an owner?

Penetration test findings left open until the next test are the Library's named mistake. Every finding needs an owner and a date, or an exception that someone with authority has accepted. If findings sit in a report, answer no.

• Yes: Is development outsourced, or is the software bought?
• No, or not known: Put each finding in the tracker with an owner and a date

Step

Put each finding in the tracker with an owner and a date

Use the same tracker as for scanner findings so one deadline model applies. Review overdue ones at the same meeting. A finding past its date needs a recorded exception, not silence.

• Then: Is development outsourced, or is the software bought?

Decision

Is development outsourced, or is the software bought?

Outsourced development and acquired systems are covered too. The Library asks you to test acquired systems against their security requirements before acceptance. If a supplier writes code for you, answer yes.

• Yes: Put requirements in the contract and test delivery on acceptance
• No: Trace a sample of recent changes through the standard

Step

Put requirements in the contract and test delivery on acceptance

Include the requirements in the tender and the contract, ask for evidence of the supplier's own practice and test before you accept. A clause library helps with the wording. Review the supplier's work as it is delivered, not only at acceptance.

• Then: Trace a sample of recent changes through the standard

Step

Trace a sample of recent changes through the standard

Pick a few changes and check each for requirements, review, scanning, testing and release approval. Skipped steps under deadline pressure with no record is the Library's named mistake. The auditor will take the same sample.

• Then: Did every sampled change follow the standard?

Decision

Did every sampled change follow the standard?

A standard nobody follows is the commonest gap. Where a step was skipped, was the reason recorded and approved? If any change skipped a step with no record, answer no.

• Yes: Secure development applied in proportion, followed and sampled
• No, or not known: Fix the cause, record the exception and sample again

Step

Fix the cause, record the exception and sample again

Find why the step was skipped: tooling, time or unclear ownership. Fix that, record the exception for the sampled change and take a fresh sample.

• Then: Trace a sample of recent changes through the standard (back to an earlier step)

Outcome

Secure development applied in proportion, followed and sampled

Keep the standard, the pipeline settings, the finding tracker and the sample result. Do not claim a secure development life cycle for software that was not in the sample, or describe scanning as testing. AI features have their own review.