ISO 27001:2022 in Safeguard: Annex A Controls, the SoA and Evidence

Safeguard helps you run the evidence side of an ISO/IEC 27001:2022 information security management system. The compliance and GRC suite (GA) checks six Annex A controls on every product scan, using the software inventory the scan builds, and tracks the rest of the ISO catalogue through automated tests, uploaded evidence, policies and attestations. When you scope a control out, Safeguard asks for a written justification and keeps it, which is the raw material for an honest Statement of Applicability.

What Safeguard does not do is certify you. Only an accredited certification body can audit your ISMS and issue an ISO/IEC 27001 certificate. Your scope, your risk method and the Statement of Applicability itself stay your decisions and your documents. This post walks through what the standard asks, how the suite maps to it, a step by step setup, and the limits you should plan around.

Key takeaways

• The compliance and GRC suite is GA. ISO/IEC 27001 is in its framework library and starts switched on in a new workspace, unless your plan or administrator removes it.
• Six Annex A requirements are decided by a scan: asset inventory (A.5.9), technical vulnerability management (A.8.8), ICT supply chain security (A.5.21), configuration management (A.8.9), control of operational software (A.8.19) and intellectual property rights (A.5.32). Each check reads the product's SBOM. SBOM generation, SCA and vulnerability management are all GA, and license compliance, which feeds A.5.32, is GA.
• Further catalogue controls, such as access control, awareness training and secure authentication, are evidenced by automated tests from connected systems, uploaded evidence, policies or a person's attestation.
• Evidence connectors are GA, with a caveat Safeguard states itself: roughly 50 are live today, and more are added on request. The docs catalogue is larger, so check a connector's card before you plan around it.
• Policy templates include a Statement of Applicability starter and an ISMS policy written for ISO/IEC 27001. A reviewer approves each version; the assistant can draft but never approve.
• The crosswalk lets accepted SOC 2 evidence count toward an equivalent ISO control, but only after a person approves that mapping.
• Evidence mapping by Lion, Safeguard's compliance model (the docs call it Lino), is GA. The Trust Center is early access.
• The readiness score is Safeguard's view of what it can see. The docs say plainly that it is not an audit opinion or a certification.

What ISO/IEC 27001:2022 actually asks for

ISO/IEC 27001 is a management system standard. It does not hand you a fixed list of security settings. It asks for a repeatable way of deciding which risks matter, choosing controls for them, running those controls and checking that they work.

The current edition was published in October 2022. The Irish National Accreditation Board's transition notice explains why: ISO's own rules allow no more than two amendments to a standard before a new edition is required, and the 2013 edition had reached that point. The 2022 edition replaced the 2013 one.

Clauses 4 to 10 in plain terms

The body of the standard runs from clause 4 to clause 10, following the common structure ISO uses for all its management system standards. In plain words:

• Clause 4, context. Understand your organisation, the issues and interested parties that affect information security, and set the scope of the ISMS. Scope is a boundary decision, and almost everything else depends on it.
• Clause 5, leadership. Top management owns the ISMS, sets an information security policy and assigns roles, responsibilities and authority.
• Clause 6, planning. Assess information security risks with a defined method, decide how to treat them, and produce the Statement of Applicability and a risk treatment plan. Set information security objectives and plan changes.
• Clause 7, support. Resources, competence, awareness, communication and documented information, including how documents are controlled.
• Clause 8, operation. Run the plans: carry out risk assessments at planned intervals and implement the risk treatment plan.
• Clause 9, performance evaluation. Monitor and measure, run internal audits (9.2) and hold management reviews (9.3).
• Clause 10, improvement. Handle nonconformities, take corrective action and keep improving.

None of these clauses can be excluded. If you claim conformity with ISO/IEC 27001, all of clauses 4 to 10 apply.

What Annex A is for after the 2022 revision

Annex A is a reference list of information security controls. In the 2022 edition it lines up with the controls in ISO/IEC 27002:2022, which gives the implementation guidance for each one. Accreditation body summaries of the change describe the shift as going from 114 controls in 14 groups to 93 controls in four themes: organisational (A.5), people (A.6), physical (A.7) and technological (A.8). Several controls were merged, and a small set was new, covering areas such as threat intelligence, cloud services, configuration management, data masking, web filtering and secure coding.

The role of Annex A is easy to misread. It is not a checklist you must implement in full. Clause 6.1.3 asks you to determine the controls your risk treatment needs, from any source, and then compare them against Annex A so that nothing necessary has been overlooked. Annex A is the cross check. The Statement of Applicability is where you record the result of that comparison.

The transition and the 2024 amendment

Two dates matter if you are planning an audit cycle.

First, the transition. The International Accreditation Forum set transition rules in its mandatory document IAF MD 26, issued in February 2023. Under those rules, certification bodies had to start initial certifications and recertifications on the 2022 edition no later than 30 April 2024, and finish moving existing clients by 31 October 2025. Ireland's national standards body states that certificates on the older edition expire after that date. If you are reading this in late 2026, any live certificate should be on the 2022 edition.

Second, the climate amendment. According to AFNOR, France's standards body, ISO and the IAF announced on 23 February 2024 a climate amendment to ISO's management system standards, ISO/IEC 27001 among them. It adds a requirement in clause 4.1 to determine whether climate change is a relevant issue, and a note in clause 4.2 that interested parties can have climate related requirements. AFNOR reports that it needs no transition period and leaves existing certificates unchanged. It does not change Annex A.

How a Statement of Applicability works

Clause 6.1.3 d) asks for a Statement of Applicability. In practice, auditors expect it to show four things for every Annex A control:

1. Whether the control is necessary for your ISMS.
2. Why you included it, usually by pointing to the risk or requirement it treats.
3. Whether it is implemented or still in progress.
4. Why you excluded any Annex A control you decided is not necessary.

The SoA is one of the documents a certification body reads first, because it ties three things together: your risk assessment, your chosen controls and the evidence that those controls run. A weak SoA usually has one of three faults. It copies Annex A and marks everything "applicable" without linking to a risk. It excludes controls with a one word reason such as "N/A". Or it was written once for the stage 1 audit and never touched again.

Our earlier post on how to write an ISO 27001 Statement of Applicability covers the document itself in depth. Here the question is narrower: where does a compliance platform fit, and where does it not?

Where "scoped out with justification" fits

In Safeguard, any requirement or control in a framework can be scoped out by a person. The docs set three rules that line up well with what an SoA exclusion needs:

• A scoped out requirement leaves the readiness score. It no longer counts for or against you.
• Scoping out needs a written justification. You cannot mark a control not applicable without giving a reason.
• The decision is recorded. The record carries the reason and who made the decision and when, so a reviewer can read it later.

That is exactly the shape of an SoA exclusion. If you treat Safeguard's scope decisions as the working register, the SoA you hand to the certification body can be generated from, or checked against, a list of decisions that already have reasons and owners attached.

Two cautions. First, scoping out a control in Safeguard does not make the exclusion valid under ISO/IEC 27001. The justification still has to follow from your risk assessment, and an auditor can challenge it. Second, the standard expects you to justify inclusions as well as exclusions. Safeguard records the exclusion reason for you; the reason a control is included lives in your risk treatment plan.

How Safeguard covers ISO/IEC 27001

Safeguard's docs describe four kinds of coverage for any framework: scan requirements, catalogue controls, automated tests and policy templates. Here is how each applies to ISO/IEC 27001.

Scan requirements: six Annex A controls decided on every scan

Every product scan in Safeguard builds a software inventory (an SBOM) and checks the framework's scan requirements against it. For ISO/IEC 27001 there are six, all decided by a scan rather than by a person. The table below restates what each one checks, in our words, based on the ISO/IEC 27001 page in Safeguard's docs.

Notice what these checks are and are not. They test whether your software inventory carries the facts each control depends on: supplier, version, hash, license and identifiers that link to vulnerability data. They do not test whether you patched a given vulnerability on time, whether your supplier contracts include security clauses, or whether someone reviewed the licenses. Those are the human halves of the same controls.

This is also why a readiness score can drop when nothing in your controls changed. A new release can pull in a component with no supplier field or no license expression. The next scan sees the gap and the A.5.21 or A.5.32 requirement fails until the inventory is complete again.

The checks rest on capabilities that are generally available on their own. CISA describes an SBOM as a nested inventory of the ingredients that make up software components, which is a close fit for what A.5.9 asks of the software part of your asset inventory. SBOM generation and analysis (GA) produces inventories in both open formats: SPDX, which is published as the international standard ISO/IEC 5962:2021, and CycloneDX, which is standardised by Ecma as ECMA-424. Software composition analysis (GA) builds the full transitive inventory across the common package ecosystems and container layers. Vulnerability management (GA) matches components against public vulnerability data, including the CISA Known Exploited Vulnerabilities catalogue. License compliance (GA) parses SPDX license expressions and sorts them into permissive and copyleft families, which is the input A.5.32 needs. If you want an external benchmark for the process side of that control, OpenChain ISO/IEC 5230 is the international standard for the key requirements of an open source license compliance programme.

Catalogue controls you evidence

The scan requirements are not the whole framework. On the ISO/IEC 27001 framework's Controls tab, Safeguard lists the scan requirements as controls, plus further Annex A controls from its control catalogue. You evidence those with automated tests, uploaded evidence, policies or an attestation.

The catalogue for ISO/IEC 27001 covers controls across all four themes. Examples from the docs include:

• Organisational: information security policies (A.5.1), threat intelligence (A.5.7), acceptable use (A.5.10), access control (A.5.15), supplier relationships (A.5.19), cloud services (A.5.23), ICT readiness for business continuity (A.5.30) and privacy of personal data (A.5.34).
• People: screening (A.6.1) and awareness, education and training (A.6.3).
• Physical: storage media (A.7.10).
• Technological: user endpoint devices (A.8.1), privileged access (A.8.2), secure authentication (A.8.5), monitoring (A.8.16), web filtering (A.8.23), secure coding (A.8.28) and change management (A.8.32).

For secure coding (A.8.28) in particular, NIST SP 800-218, the Secure Software Development Framework published in February 2022, is a widely used practice set you can cite as the basis of your secure development policy, and the Secure Development Lifecycle Policy template is a place to start writing it down.

Some controls appear in both lists. A.5.9, A.8.8 and A.8.9 are scan requirements for the software inventory side, and also catalogue controls you evidence for everything the scan cannot see, such as hardware assets, your patching process and your configuration baselines for infrastructure.

The catalogue does not cover all 93 Annex A controls. That is not a gap in your SoA; it is a gap in what Safeguard tracks. Any Annex A control you include that is not in the catalogue still needs evidence, and you keep it wherever your ISMS keeps documents today.

Automated tests and evidence connectors

Automated tests read the systems you connect: identity providers, cloud accounts, code hosts, ticket trackers, device management and more. Each test maps to one or more controls. The docs say automated tests map directly to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, and to the CIS benchmarks. ISO/IEC 27001 is one of the directly mapped frameworks, so tests land on its Annex A controls without any linking work from you.

A few details from the docs are worth knowing before you plan:

• A passing test is evidence toward a control, not proof of it. An access control is more than one setting. A test that confirms multi factor authentication is enforced supports A.8.5, but A.8.5 also covers how authentication is designed and managed.
• Some tests need no connector. A share of the tests read Safeguard's own records, such as policies, people, training and devices, rather than an external system.
• New tests have a preview period. A passing test counts toward its controls once that period ends, so do not expect a control to turn green the hour you connect a system.
• Automated tests are switched on per workspace by the Safeguard team. If the Tests area is empty, ask.

Connectors use one of three methods, depending on the system: OAuth, an API token with the narrowest read only grant the vendor offers, or the vendor's MCP server. The docs are clear that only OAuth and API token connections feed compliance tests; an MCP server connection serves Safeguard's in-app search, not the tests.

The honest caveat again: evidence connectors are GA, but Safeguard's offering files say roughly 50 are live today, with the rest available on request. The connector page for ISO/IEC 27001 in the docs lists far more connectors than that. Before you build your evidence plan around a connector, open Compliance › Connectors and check that it shows as connectable for your workspace. If it does not, use Request integration on the same page.

Policy templates, including an SoA starter

Every framework in the library gets a standard set of policy templates adapted to it. ISO/IEC 27001 also has templates written for it, including:

• Statement of Applicability (SoA)
• Information Security Management System (ISMS) Policy
• Technical Vulnerability Management Policy
• Supplier Information Security Policy
• Access Control Policy
• Secure Development Lifecycle Policy

The SoA template is a starting draft. It sets out the purpose, the selection method, and a table per theme with columns for applicability and justification. Treat its example rows as placeholders. Your justifications must come from your own risk assessment, and the template cannot know that. Lion (GA), Safeguard's compliance model, can help draft and tighten policy text, but a person still submits it for review and a reviewer approves it.

The readiness score

For each framework, Safeguard shows a readiness score: the share of in-scope requirements that pass. The rules from the docs:

• A requirement passes on a scan that finds it met, or on a person's attestation that names its evidence.
• A requirement waiting for evidence counts as not passing until someone attests it.
• A requirement scoped out with a written justification leaves the score.
• The score reads 100 only when every in-scope requirement passes.

Beside the score, Safeguard shows how many requirements a scan evaluated and how many need evidence or an attestation. That split is the useful part for an ISMS manager. It tells you how much of the number comes from machine checks and how much from people.

The docs put the limit in one line, and it is worth repeating to anyone who reads the score: it is Safeguard's assessment of what it can see, not an audit opinion or a certification. A score of 100 does not mean you will pass a certification audit.

Step by step: setting up ISO/IEC 27001 in Safeguard

These steps follow the flows in Safeguard's docs. Where the docs do not show a screen, we describe the outcome rather than invent one.

1. Confirm the framework is on. Open Compliance › Manage, then the Frameworks tab. Find ISO/IEC 27001 under International, or search for it. The docs say it starts switched on unless you switch it off. If you cannot see it at all, your Safeguard plan or administrator has not made it available; ask them. Select Save after any change.

2. Make sure the products in your ISMS scope are scanned. The six scan requirements are decided per product scan. Connect the repositories, container images or SBOM files that make up the software inside your ISMS boundary, and run a scan. The SBOM generation post in this series covers the scan options. Software outside your ISMS scope can stay in Safeguard, but keep it in a separate product so it does not muddy the ISO view.

3. Read the scan requirements first. Open ISO/IEC 27001 on Compliance › Frameworks and go to its Controls tab. Look at the six scan requirements. A failure here almost always means the inventory is missing a field: a supplier, a version, a hash or a license expression. Fix the source of the gap (a lockfile, a build step that strips metadata, a vendored component with no license file) and rescan.

4. Review the catalogue controls against your draft SoA. Go through the rest of the Controls tab with your SoA open beside it. For each control, decide whether it is in or out of your ISMS. For any control you exclude, scope it out in Safeguard with a written justification that matches the SoA wording. Do not exclude a control in Safeguard just because evidence is hard to collect; that is a risk decision, not a convenience.

5. Connect the systems that produce evidence. Open the framework's Connectors tab. It lists the connectors that answer this framework's tests, which ones you have connected and whether each connection is healthy. Connect your identity provider first, because access control, privileged access and authentication controls depend on it. Then connect cloud accounts and code hosts. On each connector's form, the "What this connector collects" panel shows which tests and evidence checks read from it, each with a switch.

6. Run the tests. Tests run on their schedule. To see results straight away, use Run now on Compliance › Tests. Expect a preview period before passing results count. If one resource legitimately fails a test, such as a break glass account that cannot use single sign on, request an exclusion on that test with a reason, an approver and an expiry date. Nothing is excluded until the approver approves it.

7. Start your policies from templates. On the framework's Policies tab, select New policy, then Start from template. Begin with the ISMS Policy and the Statement of Applicability. Edit them to match your organisation, then Submit for review. On approval, the effective date defaults to the approval day and the next review date to a year later, which matches the annual review cycle most ISMS teams already run.

8. Attest the controls that need a person. Some controls cannot be seen by any scan or test: screening, awareness training records, supplier agreements, business continuity tests. On Compliance › Evidence, upload or link the evidence against the control. Evidence starts as submitted, and a reviewer chooses Accept or Reject. Give accepted evidence an end date where it naturally expires, such as an annual penetration test report, so it shows as expiring before it lapses.

9. Decide the crosswalk mappings you rely on. If you also run SOC 2, open Compliance › Crosswalk and approve the mappings you agree with. Only approved equivalent mappings carry accepted evidence across. More on this below.

10. Read the score with its split. Back on Compliance › Frameworks, read the ISO/IEC 27001 readiness score together with how many requirements a scan evaluated and how many still need evidence. That split, not the headline number, is what goes into your internal audit plan.

What an ISO controls review looks like in practice

Here is an illustration of how the first pass usually goes. These are not results from a real tenant.

A team switches on ISO/IEC 27001 and scans three products. Five of the six scan requirements pass. A.5.32 fails on one product because a vendored JavaScript library has no license expression in the inventory. The team adds the license to the component's metadata, rescans, and A.5.32 passes. A.5.21 then fails on a later release because a new internal package was published without a supplier field. That failure is the system working: it caught an inventory gap at the release that introduced it, not at the next audit.

On the catalogue side, the identity provider connection brings in passing tests for multi factor authentication and failing tests for two dormant admin accounts. The team removes the accounts in the identity provider; the next test run passes. Awareness training (A.6.3) stays waiting for evidence until the training records are uploaded and accepted.

How the crosswalk lets SOC 2 evidence count toward ISO controls

Many teams reach ISO/IEC 27001 after a SOC 2 report, or run both. The controls overlap heavily: both want access reviews, change management, vulnerability management and supplier oversight. Collecting the same evidence twice is waste.

Safeguard handles this with a crosswalk across SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and NIST SP 800-53. NIST publishes its own informative references (mappings) between CSF 2.0 and other frameworks, a reminder that mapping is a published, reviewable judgement, not an automatic equivalence. A suggested mapping links a control in one framework to a control in another. The rules from the approvals docs are strict:

• A reviewer decides each mapping. On Compliance › Crosswalk, a reviewer chooses Approve, Reject with a reason, or Withdraw decision.
• Only equivalent mappings carry evidence. Approving an equivalent mapping makes accepted evidence for the source control count toward the target control in your programme. Approving a partial mapping confirms the suggestion but makes nothing count.
• Decisions are append only. Each decision is a new record and the latest one counts. History is never edited or deleted.
• Decisions are tied to the mapping text. If a later crosswalk version changes a mapping, your earlier approval no longer applies, and someone has to decide again.

Why so careful? Because a SOC 2 criterion and an ISO control can look alike and still differ in scope. SOC 2 logical access criteria and ISO A.5.15 both cover access control, but an ISO auditor will ask how access control follows from your risk assessment and your SoA, which a SOC 2 auditor does not. Requiring a person to approve equivalence keeps the shortcut defensible. Our crosswalk post covers the general method.

Tests are a different path. Automated tests map directly to ISO/IEC 27001 controls, so a test result counts for ISO and SOC 2 at the same time without any crosswalk approval. The crosswalk matters for evidence that does not come from a mapped test: uploaded documents, attestations and policy approvals.

How internal audit and management review use the suite's records

Clause 9 is where many first time ISMS programmes struggle. The controls run, but nobody can show the system checks itself.

Internal audit (9.2)

Clause 9.2 asks for internal audits at planned intervals, with an audit programme, defined criteria and scope, objective auditors, and reported results. Safeguard does not run the internal audit for you, and it does not replace the independence the standard expects of an internal auditor. What it gives the internal auditor is a record to test:

• The Controls tab shows each control's current state, the evidence behind it and when that evidence was accepted and by whom.
• Scoped out controls carry their justification and owner, so the auditor can check each one against the SoA.
• Policy records show which version is in force, who approved it and when the next review is due.
• Test history shows whether a control passed continuously or only on the day someone looked.

A practical pattern: plan internal audits by Annex A theme across the year, and for each one, export the controls and evidence for that theme as the starting sample. The auditor then tests a selection of the underlying records rather than rebuilding them.

Management review (9.3)

Clause 9.3 asks top management to review the ISMS at planned intervals, considering, among other inputs, feedback on performance, audit results, monitoring and measurement results, and the status of risk treatment. The readiness score, with its split between scan evaluated and evidence needed, and the list of failing or expiring controls, are reasonable inputs to that meeting. The minutes and decisions belong to management. Record them as evidence against your management review control so the next auditor finds them in the same place as everything else.

Annex A areas, what Safeguard does, and what you still own

What stays yours

Scope. Clause 4.3 asks you to set the boundaries of the ISMS. Safeguard's products are a useful map of the software inside it, but the scope statement is a management decision, and the certificate's wording comes from it.

Risk method. Clause 6.1.2 asks for a defined risk assessment process that gives consistent, comparable results, and ISO/IEC 27005:2022 gives guidance on building one. ENISA's Interoperable EU Risk Management Framework (2022) helps compare methods if a regulator or customer uses a different one. Safeguard's Risks area can hold the register, with owner acceptance for low and medium residual risk and an admin approver plus a review date within a year for high and critical. The method and the acceptance criteria are yours to defend.

The certification audit. An accredited certification body runs a stage 1 documentation review and a stage 2 audit of how the ISMS operates, then surveillance audits and recertification. Safeguard prepares the record they test. It never issues an opinion or a certificate, and it does not arrange the audit.

What Safeguard does not do

• It does not certify you or audit you. Only an accredited certification body issues an ISO/IEC 27001 certificate. A readiness score, at any value, is not an audit opinion.
• It does not write your SoA or your risk assessment. It gives you a template and keeps your scope decisions with their reasons. The justification for each control, and the link to a risk, must come from your own analysis.
• Its scan checks cover software inventory facts only. The six scan requirements test supplier, version, hash, license and identifier data in the SBOM. They say nothing about physical security, HR processes, supplier contracts or whether a patch was applied within your policy timeline.
• It does not track every Annex A control. The catalogue covers a subset across the four themes. Any control you include outside that subset needs evidence kept elsewhere or uploaded manually.
• It sees only what you connect. Roughly 50 evidence connectors are live today. Systems that are not connected, or connected with too narrow a grant, produce no tests, and the score will not tell you they are missing.
• It does not make decisions for you. Safeguard's assistant and MCP clients such as Claude can draft and submit, but they never accept evidence, approve policies or approve crosswalk mappings. A person with a reviewer role does.
• It does not change which frameworks you can use. Your Safeguard plan decides which frameworks your organisation can choose from.

Common mistakes

Treating the readiness score as an audit result. A high score means the requirements Safeguard can see are passing. It does not mean the controls outside its view are in place, or that an auditor will agree with your scope decisions. Always report the score with the split between scan evaluated and evidence needed.

Scoping out controls to raise the score. Because a scoped out requirement leaves the score, excluding hard controls makes the number go up. An auditor will read the justification, and an exclusion that does not follow from the risk assessment is a nonconformity waiting to happen. Write each justification as if the auditor will read it, because they will.

Copying the SoA template without changing the rows. The template's example applicability and justifications are placeholders. An SoA that says "cloud services in use" for every organisation is not an SoA.

Counting connectors that are not live. The docs catalogue lists many connectors. Only roughly 50 are live today. Check before you promise an auditor automated evidence from a given system.

Approving partial crosswalk mappings and expecting evidence to move. Only equivalent mappings carry accepted evidence. A partial mapping confirms the relationship and nothing more.

Forgetting the inventory gaps that new releases introduce. A product that passed all six scan requirements last quarter can fail one today because a new dependency has no supplier or license data. Fix the source, not the symptom.

FAQ

Does Safeguard make my company ISO 27001 certified?

No. Only an accredited certification body can audit your ISMS and issue an ISO/IEC 27001 certificate. Safeguard's compliance and GRC suite (GA) helps you prepare by checking six Annex A controls on every scan, tracking evidence for further catalogue controls and keeping a record of policies and decisions. The docs say the readiness score is not an audit opinion or a certification.

Which ISO 27001 Annex A controls can Safeguard check automatically?

Six are decided by a product scan: A.5.9 (asset inventory), A.8.8 (technical vulnerabilities), A.5.21 (ICT supply chain), A.8.9 (configuration management), A.8.19 (operational software) and A.5.32 (intellectual property rights). Each checks the software inventory for the data the control depends on. Further controls, such as access control and secure authentication, are supported by automated tests from connected systems, which are evidence toward the control rather than proof of it.

Can Safeguard generate my Statement of Applicability?

It gives you an SoA policy template written for ISO/IEC 27001 and records every control you scope out with its written justification. It does not decide what is applicable. Your SoA must follow from your own risk assessment, and a reviewer must approve it.

How many Annex A controls are there in ISO 27001:2022?

Ninety three, grouped into four themes: organisational, people, physical and technological. The 2013 edition had 114 controls in 14 groups. The 2022 Annex A lines up with ISO/IEC 27002:2022, which gives guidance for each control.

Can I reuse my SOC 2 evidence for ISO 27001 in Safeguard?

Yes, in two ways. Automated test results map directly to both frameworks, so they count for both. For other evidence, a reviewer approves crosswalk mappings on Compliance › Crosswalk; only equivalent mappings let accepted SOC 2 evidence count toward the ISO control. Partial mappings carry nothing.

Is ISO 27001 switched on by default in Safeguard?

The docs say ISO/IEC 27001 is on in your workspace unless you switch it off in Compliance › Manage. Your Safeguard plan decides which frameworks are available, so if you cannot find it, ask your Safeguard administrator.

Does the readiness score include controls I scoped out?

No. A requirement a person scopes out, with a written justification, leaves the score. Requirements waiting for evidence stay in the score as not passing until someone attests them.

Can Claude or another AI assistant approve ISO evidence in Safeguard?

No. Safeguard's docs say its assistant and MCP clients can draft and submit changes but never accept, approve, launch or acknowledge anything, whoever is signed in behind them. A person with a reviewer role makes those decisions in the app.

Does the 2024 climate amendment change Annex A?

No. The 2024 amendment adds a requirement in clause 4.1 to determine whether climate change is a relevant issue, and a note in clause 4.2 about climate related requirements of interested parties. Annex A is unchanged.

From an inventory gap to a fixed control

The scan requirements fail for a reason you can act on: a component without a supplier or license, or a vulnerable version that A.8.8 says you must evaluate and treat. Treating it usually means replacing that component, and the control only turns green again when the fixed version ships and the next scan sees it.

For the vulnerability side, prioritise first. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, alongside EPSS and the CISA KEV catalogue; our prioritisation post explains the signals. Policies and gates (GA) can then stop a release that adds a known exploited vulnerability, which is the kind of operating evidence an A.8.8 auditor likes to see. For license gaps behind A.5.32, see the license obligations post. For the supplier side behind A.5.19 to A.5.22, see supplier software risk with Safeguard TPRM.

A failing A.8.8 control is, underneath, a vulnerable dependency that someone has to replace. The next section describes how Safeguard helps you make that fix, which is what turns the control green again on the next scan.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows connecting Claude to the Safeguard MCP server (GA) with OAuth and choosing which tools Claude can use. In Claude, add Safeguard from the connector directory, where it has a community listing: open the entry, connect, sign in to Safeguard, check the app name and host, then Authorize access. On a Team or Enterprise plan an Owner adds it first. With the default read only tools, an ISMS manager can ask which products carry known exploited vulnerabilities before a management review; which other tools appear depends on your plan and your administrator's settings, and none of them approve evidence.

Click through it at your own pace, or open it full screen.

The second demo is a real session in the Safeguard desktop app (early access, beta). The CLI session shows in the desktop app's conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. When the A.8.8 scan requirement or a vulnerability finding is what holds your ISO view back, this is the approve each step flow that gets the fix in, after which the next scan updates the control.

Click through it at your own pace, or open it full screen.

To try it on your own products, download the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. For the full list of capabilities and their labels, see what Safeguard does today. For a supply chain view of the same standard, see building an ISO 27001:2022 aligned supply chain programme.

Quick check

Sources

• Safeguard docs: ISO/IEC 27001 framework page
• Safeguard docs: Compliance frameworks
• Safeguard docs: ISO/IEC 27001 and connectors
• Safeguard docs: Approvals
• Safeguard docs: Compliance connectors
• INAB: Transition requirements for ISO/IEC 27001:2022 (NF38)
• NSAI: ISO/IEC 27001:2022 transition policy
• NIST: Cybersecurity Framework 2.0
• NIST SP 800-218, Secure Software Development Framework v1.1
• CISA: Software Bill of Materials
• CycloneDX: specification overview
• SPDX: overview
• OpenChain: ISO/IEC 5230 license compliance
• ENISA: risk management
• AFNOR: The climate, a game changer for management standards

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.