ISO/IEC 27701 does not have a clause called "software supply chain." You map to it through duties it does have: knowing who processes personal data, treating privacy risk, securing the processing, and managing suppliers. Your dependency inventory, vulnerability handling and vendor checks become evidence for those duties.
This is a reading of how the pieces fit, not the text of the standard. Use your copy of the standard and your auditor's guidance for exact control wording.
What changed in the 2025 edition?
BSI describes BS EN ISO/IEC 27701:2025 as a stand-alone Type A management system standard, no longer dependent on ISO/IEC 27001 or 27002. It aligns to ISO's Harmonized Structure, so the management system requirements sit in the core clauses, and privacy-specific risk assessment and treatment are embedded there. BSI also says the existing controller, processor and subcontractor requirements were consolidated into a single annex structure, with numbering and layout updated.
Two consequences matter for engineering teams. You no longer read the standard as a set of add-ons to a security management system, and you should not rely on control numbers from the 2019 edition in a new mapping.
Why does a dependency list matter for a privacy standard?
Because software components are where personal data gets processed, stored, logged and sent elsewhere. A privacy management system has to know where personal data flows. If a library phones home, writes request bodies to a log, or ships to an analytics endpoint, that is a processing activity you may not have recorded.
An SBOM will not tell you that by itself. It tells you what components are present, which is the start of the question "what could touch personal data?" You then add what each component does with data.
A working map
- Know the processing and the parties involved: keep an SBOM for each service, with an owner and a note on which services handle personal data.
- Treat privacy risk: add risk register entries for components that handle personal data, with vulnerability status.
- Secure the processing: keep vulnerability scan results, patch timelines, malicious package checks and secrets scanning.
- Manage suppliers and subcontractors: list third-party software and services that process data, with contract and review dates.
- Handle incidents: add runbook entries for a vulnerable or compromised component, with decision records.
- Keep records and accountability: store dated exports of scans, policy decisions and exceptions with approver names.
The first half of each line is where an auditor starts. The second half is where an engineering team usually has data already.
Where do teams go wrong?
- Treating the SBOM as the control. The control is the process that keeps it current and acts on it.
- Mapping everything to everything. A map with forty rows per control is unreadable. Pick the two or three best pieces of evidence for each duty.
- Forgetting the role. The 2025 text distinguishes controllers and processors. A SaaS company is often both, depending on the data. The evidence you owe differs by role.
- Ignoring AI services. If a feature sends personal data to a model provider, that provider is a processor or subprocessor for the purposes of your records.
How do you use a tool without handing it the judgment?
Safeguard's framework library lists ISO/IEC 27701. Per the docs, each framework page says what a scan checks, which requirements a scan can decide, and which need your evidence. That split is the useful part: a scan can show that vulnerabilities were found and handled, but only people can decide that a purpose for processing is legitimate. Automated evidence supports your management system. It does not certify it, and Safeguard does not certify anyone.
Open the full walkthrough at /demos/framework-mapping.
What to do
- Decide your role per service: controller, processor or both.
- Generate an SBOM per service and attach an owner and a data classification.
- List third-party components and services that receive personal data, and the contract that covers each.
- Choose one primary evidence item per duty in the map above and store dated copies.
- Write down how often each item is refreshed, and who checks.
- Ask your certification body how it treats transition from the 2019 edition before you spend on a mapping against old numbering.
Quick check
Do I need ISO 27001 before ISO 27701?
Under the 2025 edition, BSI describes the standard as no longer dependent on ISO/IEC 27001 or 27002. Check with your certification body for how it scopes an audit.
Is an SBOM enough evidence for the processor duties?
No. It shows what components exist. You also need records of which parties process personal data, the contracts, and the actions you took on findings.
Sources
- BSI, Reimagining data privacy compliance with BS EN ISO/IEC 27701:2025
- Safeguard docs: Compliance
- Safeguard docs: All frameworks
Last reviewed: 18 October 2026.
