Does ISO 42001 cover GDPR for AI systems that process personal data?
ISO/IEC 42001 does not replace GDPR compliance. A customer, contract or regulator that asks for ISO 42001 while your AI system processes personal data is asking for a certifiable AI management system, not a privacy assessment. ISO/IEC 42001 is a certifiable management system, and GDPR obligations stay in force regardless of certification. The two overlap in practice: the same evidence (a documented description of the processing, data acquisition and provenance records, and an assessment of impacts on individuals) can often serve a DPIA under Article 35 and an AI impact assessment under the Annex A impact controls. Your organization owns both the ISO 42001 management system and its GDPR duties. An implementation partner can prepare systems and evidence, but only an independent certification body can certify ISO 42001, and only the controller or processor can make the GDPR determinations.
ISO/IEC 42001 has no privacy-specific control set of its own. Its Annex A controls are AI governance controls, and the link to GDPR exists only where your scope and statement of applability, required by clause 6.1.3, include the controls that touch personal data. Review the data controls in A.7, including the control on acquisition and selection of data (A.7.3), and the impact assessment controls in A.5 with the GDPR questions in mind. Then decide, and document in the statement of applicability, which controls cover personal data processing and which GDPR duties still need their own records. Ask the certification body early how it will test that boundary, because an exclusion without a justification is a common reason for findings.
Before scoping, confirm three things with your privacy office: which AI systems process personal data, whether any of them make decisions that fall under Article 22, and whether a DPIA already exists for each. Where a DPIA exists, check whether it covers the AI-specific risks, such as training data provenance and model behavior, or only the original processing purpose. Where a DPIA is missing, plan for it as a separate deliverable with its own owner and sign-off, since the management system does not produce a legal assessment on its own. The EU AI Act fundamental rights impact assessment, where it applies, is a further assessment that complements a DPIA rather than replacing it.
How a DPIA under Article 35 fits into an ISO 42001 impact assessment
A DPIA under GDPR Article 35 and an ISO/IEC 42001 impact assessment under A.5 often examine the same AI system from different angles. The cards below show which triggers, minimum content and record links let one body of evidence serve both, and where the organization must keep its own judgment.
Deciding when a DPIA is required
Article 35(1) requires a DPIA before processing likely to result in high risk to individuals, particularly where new technologies are used. Article 35(3) names three cases: systematic and extensive automated evaluation with legal or similarly significant effects, large-scale special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area. The organization owns the trigger decision and must record it. A partner can prepare a screening checklist mapped to each AI use case so the decision is repeatable and visible to an assessor.
Minimum content of a DPIA
Article 35(7) sets four minimum elements: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to data subjects, and the measures envisaged, including safeguards and security measures. For an AI system, the description should cover training and inference data flows, model purpose and the people affected. The organization owns the risk judgments and the sign-off. A partner can help structure the document and collect the technical facts on data flows, logging and access controls.
One assessment for similar operations
Article 35(1) allows a single assessment to address a set of similar processing operations that present similar high risks. This suits a platform that runs the same scoring model across several business lines or customer segments. The organization must confirm that the operations really share purpose, data categories and risk profile, and document that reasoning. A partner can map which AI systems share those characteristics and draft the grouping rationale for review by the DPO.
Referencing the DPIA from the A.5 records
Annex A control A.5 asks for an AI system impact assessment process and documentation, including a separate look at impacts on individuals or groups and on society. Rather than writing the privacy analysis twice, the A.5 record can state the DPIA reference, its date and version, and the risks it covers, then add the non-privacy impacts such as fairness, safety and societal effects. The organization owns the cross-reference and its currency. A partner can set up the document structure and link the two records in the management system.
Automated decisions under Article 22
Article 22(1) gives a person the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significant effects. Where an AI system makes or strongly drives such decisions, the DPIA must address the safeguards, human review and the ability to contest outcomes. The organization decides whether a human is meaningfully involved and must test that claim. A partner can help design review workflows and produce logs that show reviewer action.
Fundamental rights assessment under the AI Act
Article 27 of the EU AI Act requires certain deployers to assess fundamental rights impacts before deployment, and where a GDPR DPIA already covers some of those obligations, the fundamental rights assessment complements it. Results must be notified to the market surveillance authority. The organization decides whether the Article 27 duty applies to its system and owns the notification. A partner can prepare a combined record structure so the DPIA and the rights assessment share facts without contradicting each other.
When Article 22 rights change the AI design
Article 22(1) of the GDPR gives individuals the right not to be subject to a decision based solely on automated processing, including profiling, where that decision produces legal effects concerning them or similarly significantly affects them. The design question is whether a person meaningfully shapes the outcome. If a model's output is applied automatically to decide credit, insurance pricing, hiring, benefits or account closure, the system falls squarely within the concern and needs a documented legal basis and safeguards before launch.
- Legal or similar effects: Refusing a loan, ending a contract or rejecting a job applicant usually qualifies. Confirm the threshold for each use case rather than assuming.
- Exceptions and safeguards: Automated decisions may be permitted in narrow circumstances, and the individual must then have a way to obtain human intervention, express a view and contest the decision. Confirm with counsel which exception applies.
- Special category data: Stricter limits apply when decisions draw on health, biometric or other sensitive data. Map these inputs before the model is trained.
- DPIA trigger: Systematic automated evaluation with legal or similarly significant effects requires a DPIA under Article 35(3), so the design work and the impact assessment should happen together.
- Enforcement example: The Dutch DPA fined Uber EUR 824 990 000 on 8 October 2026 for unlawful automated decision-making, as EDPB news on the decision reports only in general terms. Treat it as an illustration of regulator attention, not as a rule for your system.
Check whether any production path can change a person's position without a named reviewer who has authority to decide.
A human in the loop removes the Article 22(1) concern only when the reviewer can actually influence the outcome. The Article 29 Working Party guidance on automated individual decision-making and profiling (WP251) treats human involvement as something that must be meaningful. A reviewer who approves model output without the information, time or authority to disagree is a formality, and a regulator will likely treat the process as automated. The design goal is a review step that could produce a different result.
- Authority: The reviewer can change or overturn the outcome, and the process allows it without penalty or escalation barriers.
- Information: The reviewer sees the underlying inputs, the main factors behind the score, known limitations and the confidence of the output, not only a single verdict.
- Competence and workload: Training and case volumes should allow genuine assessment. Ask how long reviewers spend per case.
- Accountability: Each review role appears in the A.3 record of AI roles and responsibilities, so an assessor can see who owns each decision.
- Override monitoring: Track how often reviewers change the model's recommendation. A reviewer who never disagrees is evidence that the review step may not work.
Ask for review logs that show overrides, reviewer identity and the reasons recorded, then test whether those logs match what staff say happens.
When AI output informs a decision that a person makes and owns, Article 22(1) may not be triggered, but the conclusion depends on how the process works in practice. The useful question is who actually decides. A score that staff follow in nearly every case can behave like an automated decision even though a person signs the form. Decision support still processes personal data, so the DPIA, transparency duties and data protection principles continue to apply.
- Decision ownership: The human decision-maker has the authority and the information to reach a different conclusion and records reasons for the outcome.
- Default behavior: If the recommendation is applied unless someone intervenes, treat the process as automated for Article 22 purposes until counsel concludes otherwise.
- Output design: Present supporting factors, uncertainty and alternatives so the output informs judgment instead of replacing it.
- Drift over time: Compare decisions with and without the model's input across periods. Convergence on model output is a signal to review the process.
- Staff guidance: Written instructions should state when the model may inform a decision and when it must not be used as the basis.
Confirm the classification with counsel and check actual override behavior in logs, not only the job description or the policy text.
ISO/IEC 42001 gives an organization a structure for showing how Article 22 design choices were made and kept working after launch. The A.6 controls on the AI system life cycle cover design, verification and validation, deployment, operation, technical documentation and event logs. The A.9 controls on use cover responsible use, objectives that guide use and keeping use within the intended purpose. Together they produce the evidence trail that a regulator, an auditor or a customer's data protection team will ask for.
- Intended use record: A documented purpose that states whether the system makes or supports decisions about people. This record is the starting point for the Article 22 analysis.
- Design and verification records: Evidence that the human review step, fallback and contest route were specified, built and tested before release.
- Operational logs: Event logs that record the model version, categories of inputs, outputs, reviewer identity, overrides and retention period, as the organization's policy defines.
- Use boundary controls: Procedures that detect use beyond the intended purpose, such as a scoring model reused for a new type of decision without a new assessment.
- Link to impact assessments: Keep these records with the DPIA under Article 35 and, where the EU AI Act applies, the fundamental rights impact assessment that complements it.
Confirm log retention, access rules and the content of personal data in logs with counsel and the data protection officer before relying on them as evidence.
Documenting personal data acquisition and provenance for AI
This sequence turns the acquisition and selection requirement in Annex A control A.7.3 into a dataset register that links each personal data source to its lawful basis, quality and provenance checks, DPIA and retention rules, so an assessor or regulator can trace every training and operational dataset back to its origin.
Inventory data sources and personal data categories
The data owner for each AI system lists every dataset that feeds training, validation, fine-tuning, retrieval or operation, including third-party and scraped sources. For each dataset, the privacy lead marks whether it contains personal data and which categories apply, with special category and criminal offence data flagged separately. The output is a data source register with one row per dataset, its origin and its owner. The step is complete when every AI system in the statement of applicability has a register entry and the privacy lead has signed the personal data flags.
Record lawful basis and purpose for each dataset
The privacy lead, with legal input, records the purpose for which each personal data category is processed by the AI system and the GDPR lawful basis relied on for that purpose. Purposes are written narrowly enough to test later, because a dataset collected for one purpose cannot be reused for an unrelated AI purpose without a separate justification. The output is a purpose and lawful basis record linked to each register row. Confirm with counsel where a dataset was collected under a different purpose than the one now proposed.
Document selection and acquisition under A.7.3
The AI product owner documents how each dataset was selected and acquired: the selection criteria, the acquisition method, the contract or collection notice that applies, the dates of acquisition and any exclusions. This record addresses the requirement in control A.7.3 to determine and document the details of data acquisition and selection, and the guidance in Annex B for that control. The output is an acquisition record for each dataset, reviewed by the AI governance owner before the dataset is approved for use.
Check data quality and provenance
The data engineering team traces each dataset back to its source, records transformations and versions, and checks quality against the criteria set in the data quality control. For personal data, they confirm that the accuracy checks and the removal of records outside the stated purpose have run and are logged. The output is a provenance record per dataset with version identifiers, transformation history and quality results. The step is closed when a reviewer can reproduce the dataset lineage from the record without asking the team.
Link each dataset to the DPIA
The privacy lead maps each dataset in the register to the DPIA for the AI system that uses it. Where the processing is likely to be high risk, Article 35 requires a DPIA before processing begins, and the DPIA must describe the processing, assess necessity and proportionality, assess risks to individuals and set out safeguards. Where the AI system is subject to the EU AI Act, the fundamental rights impact assessment complements the DPIA rather than replacing it. The output is a cross-reference table between datasets and DPIA sections, dated and approved by the data protection officer or equivalent.
Set retention and deletion rules per dataset
The privacy lead and the system owner define how long each personal data dataset may be kept, including training copies, derived artifacts, logs and backups, and the trigger for deletion or anonymization. Retention rules must match the purpose and lawful basis recorded earlier. The output is a retention schedule that names each dataset, its retention period and deletion method, and states who approves exceptions. Confirm the retention periods with the legal team, since no general period applies across AI systems.
Review and maintain the register
The AI governance owner reviews the register at the schedule set in the management system, and whenever a dataset, source, purpose or AI system changes. Each change produces a new version of the affected records and a note in the change log that links to the DPIA update. The output is a versioned register with a review history that an internal auditor can sample. The step is complete for the period when the auditor can trace a sampled dataset from its register entry to its acquisition record, provenance check, DPIA and retention rule.
How the EU AI Act fundamental rights impact assessment complements a DPIA
A fundamental rights impact assessment (FRIA) under Article 27 of the EU AI Act is a separate assessment from a GDPR data protection impact assessment, but the two overlap where an AI system processes personal data and affects people's rights. Under Article 27, certain deployers of high-risk AI systems must carry out a FRIA before putting the system into use, and must notify the market surveillance authority of the results. Where a DPIA already covers some of the same obligations, the FRIA complements it rather than replacing it. Whether you are in scope depends on your type as a deployer (for example, public bodies and certain private entities providing public services, or deployers of specific high-risk use cases such as credit scoring or insurance pricing) and on the use case itself. Confirm both with counsel before you assume the duty applies.
Practically, the most efficient approach is to run one structured assessment that records the shared elements once: the systematic description of the processing and its purposes, the necessity and proportionality analysis, the risks to individuals, and the safeguards and security measures. The FRIA then adds the fundamental rights analysis that a DPIA does not require on its own, such as effects on non-discrimination, freedom of expression, access to services and human dignity, and the human oversight and complaint mechanisms in place. Keep the DPIA as the record for GDPR accountability and the FRIA as the record for the AI Act, and cross-reference them so an assessor can trace each measure to both. Your ISO/IEC 42001 impact assessment controls (A.5) can hold this combined evidence.
Timing needs checking as well. Article 113 sets the dates on which different AI Act obligations begin to apply, and the Article 27 obligation follows its own application date. Confirm with counsel which date governs your system before you plan the assessment, and confirm which national authority you must notify. Ask your DPO and legal team to sign off on the boundary between the two documents, because a gap in either one is the most common reason a regulator questions the assessment.
ISO 27701 and ISO 27091 next to ISO 42001
ISO/IEC 42001 governs the AI management system, but AI that handles personal data also needs a privacy management layer and privacy risk guidance. ISO/IEC 27701:2025 is the certifiable standard for that layer, while ISO/IEC FDIS 27091 is still pending and can only inform your approach for now.
ISO/IEC 27701:2025 privacy management
ISO/IEC 27701:2025 sets requirements for a privacy information management system for organizations acting as PII controllers or processors. ISO describes it as an independent management system standard that aligns with an existing ISO/IEC 27001 system, so you can extend one management system rather than build two. For AI, check whether your privacy controls cover training data, inference logs and sub-processors, and confirm with an accredited certification body whether certification against it fits your scope. Confirm the current edition status with ISO.
ISO/IEC 27701 as a certification target
ISO/IEC 27701 is the standard you can certify against, but only through an external certification body. ISO does not certify organizations itself. Ask whether the certification scope covers the AI product, the data pipelines feeding it and the processor role you hold for customers. Ask your auditor how they will test evidence for lawful basis, retention and data subject requests on AI workloads. DeployOpen can prepare systems and evidence, but it does not issue certificates.
ISO/IEC FDIS 27091 privacy risk guidance
ISO/IEC FDIS 27091 covers identifying, evaluating and treating privacy risks in AI systems and machine learning models. It reached stage 50.00, FDIS registered for formal approval, on 13 July 2026, and it is not yet published. Treat it as guidance you can draw on for privacy risk assessment, not as a certifiable requirement. Confirm its publication status with ISO before you cite it in a contract or a DPIA.
Using 27091 alongside ISO 42001
ISO/IEC 42001 requires you to assess AI impacts, and a DPIA addresses risks to individuals under GDPR. Until 27091 is published, map its privacy risk concepts onto your existing AI risk register and impact assessment records rather than claiming conformity to it. Document which privacy risk method you used, who approved it and how it feeds the statement of applicability. Ask your assessor whether they expect a named method for AI privacy risk.
Privacy and security controls together
ISO/IEC 27701 extends the privacy controls around the information security controls in ISO/IEC 27001. For AI systems, the overlap matters most for access to training datasets, logging of personal data in model inputs and outputs, and deletion across backups and vector stores. Assign one owner for the shared controls so the privacy evidence and the security evidence do not contradict each other during audit.
What a GDPR-aligned ISO 42001 project costs and who is paid
This table compares each cost component of a GDPR-aligned ISO 42001 project by who is paid, whether the cost is one-time or recurring, and what drives it up. Use it to structure a request for a written scope and quote, since no prices or durations are supplied for this work. The main takeaway is that the certification body, your own staff and any implementation partner are paid for different things, and only the certification body issues the certificate.
| Cost component | Who is paid and for what | One-time or recurring, and main drivers |
|---|---|---|
| Certification body audit fees | The accredited certification body, for the stage 1 and stage 2 audits and certificate issuance. It is independent of any consultant. | Mostly one-time for initial certification, then recurring for surveillance audits. Drivers include the number of AI systems in scope and the count of personal data processing activities. |
| Surveillance and recertification audits | The certification body, to confirm the AI management system and its privacy-related controls keep operating. | Recurring. Drivers include how many AI systems process personal data and how often DPIAs and data provenance records change. |
| Internal privacy and DPO time | Your own staff, including the DPO, for DPIA reviews, records of processing and sign-off on A.5 and A.7 evidence. | Recurring in practice, with a larger one-time load at the start. Drivers include the number of AI use cases and the maturity of existing GDPR records. |
| Legal review | External counsel or in-house legal, for lawful basis, Article 22 analysis of automated decisions and transfer questions. | Mostly one-time per system, plus review when processing or the law changes. Ask whether the quote includes legal review or excludes it. |
| Implementation partner scoping and evidence preparation | An implementation partner, for scoping, gap analysis, DPIA drafting support and assembling evidence. The partner prepares evidence but does not issue reports or certificates. | One-time for the initial project, then optional retainer work. Drivers include the number of systems, data sources and existing ISO 27001 or privacy documentation. |
| Tooling and infrastructure | Your organization, for software, hosting and logging needed to keep governance and privacy evidence. Open-source options still carry hosting and administration effort. | Mixed. Setup is one-time, while hosting, backup and maintenance recur. Drivers include whether tools run in your own cloud or air-gapped network. |
| Scope and quote | Ask every provider for a written scope listing systems, deliverables, responsibilities and exclusions before work starts. | Confirm with each provider which items are fixed-scope and which are retainers, and what changes trigger a new quote. |
Questions buyers ask about ISO 42001 and GDPR
Does ISO 42001 certification satisfy GDPR?
No. ISO/IEC 42001 certification shows that an organization runs an AI management system, but it does not establish GDPR compliance. GDPR sets legal duties for the controller, including a lawful basis, transparency, data subject rights, and a DPIA where Article 35 applies. A certificate issued by an external certification body does not replace any of those duties. Treat ISO 42001 as a governance structure that can hold GDPR evidence, such as the impact assessment records and data acquisition controls described in Annex A, and confirm with a privacy lawyer or your data protection officer which GDPR obligations apply to each AI use case.
Is a DPIA required for every AI system that uses personal data?
No, but many AI systems that use personal data will need one. Article 35(1) requires a DPIA before processing that is likely to result in a high risk to individuals, particularly when new technologies are used. Article 35(3) names three cases where a DPIA is required in particular: systematic and extensive automated evaluation with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area. A single assessment may cover a set of similar operations with similar high risks. Document the screening decision for every system, including the systems where you conclude a DPIA is not required.
Who signs off the DPIA?
The controller signs off the DPIA, and the controller remains accountable for it. Under GDPR, the controller must seek the advice of its data protection officer where one is designated, and the assessment must describe the processing, its necessity and proportionality, the risks to data subjects, and the measures taken to address them. Engineering, security and product teams supply the technical inputs, and an implementation partner can prepare the system documentation and evidence, but neither can approve the assessment on the controller's behalf. Confirm the sign-off chain, including who accepts residual risk, before the assessment starts.
Can DeployOpen run the DPIA for us?
DeployOpen can prepare the systems, technical descriptions and evidence that a DPIA needs, but it does not decide the assessment. The controller owns the DPIA, makes the necessity and proportionality judgments, and accepts the residual risk. DeployOpen's role typically covers mapping data flows across self-hosted platforms in your own infrastructure, documenting data stores and access paths, configuring the safeguards you select, and testing that those safeguards operate. Ask any partner to state in the written scope which DPIA inputs it will produce and which decisions remain with your staff or your counsel.
How much internal effort does a GDPR-ready AI DPIA take?
The effort depends on how many AI systems process personal data, how well their data flows are already documented, and how many teams must contribute. Internal effort usually falls into three groups: privacy and legal review, engineering time to describe data flows and retention, and security time to confirm safeguards. A first assessment for a single system with undocumented data flows takes far more effort than an update to a documented system, and a single assessment can cover similar operations with similar risks. Ask any provider for a written list of the artifacts it will produce, the people it needs from your organization, and the review cycles included in the quote.
Is ISO 27701 needed for AI systems that process personal data?
ISO 27701 is not required by GDPR, but it is useful when you need a structured privacy information management system. ISO/IEC 27701:2025 sets requirements and guidance for a privacy information management system for PII controllers and processors, and ISO describes it as aligned with existing ISO/IEC 27001 systems. For AI, ISO/IEC FDIS 27091 is also relevant because it gives guidance on identifying, evaluating and treating privacy risks in AI systems and machine learning models. Adopt ISO 27701 when your organization already runs or plans an ISO 27001 system and needs a privacy layer across all processing, and confirm with your certification body whether it fits your scope.
What does the EU AI Act fundamental rights impact assessment add to a DPIA?
It covers a different set of impacts, so it complements the DPIA rather than replacing it. Under Article 27 of the EU AI Act, deployers in the scope of the article must assess impacts on fundamental rights before deploying certain high-risk AI systems and must notify the market surveillance authority of the results. Where a GDPR DPIA already covers some of the same obligations, the fundamental rights assessment builds on it. Plan one shared data inventory and risk register so that both assessments draw on the same evidence.
What usually delays AI privacy evidence and how to avoid it
Most delays in AI privacy evidence come from a few predictable gaps: unclear scope, missing records of where data came from, late assessments and unassigned decisions. Each card names one gap and the step that closes it before an assessor or data protection authority asks.
Treating ISO 42001 as a GDPR substitute
ISO/IEC 42001 sets requirements for an AI management system, but it does not replace the GDPR's obligations on lawful basis, data subject rights or processor contracts. Teams that pass an ISO 42001 audit still need separate privacy evidence. Map each GDPR duty to a named record in the privacy file, and confirm with counsel which duties the ISO controls do not cover.
Leaving AI systems out of scope
An AI system that processes personal data is often missed because it sits inside a product feature, a vendor tool or an internal analytics pipeline. Build an inventory of every AI system, mark each one that touches personal data, and record the owner. Re-check the inventory whenever a new model, prompt source or data feed is added.
Missing data provenance records
Annex A control A.7.3 asks the organization to determine and document how data used in AI systems is acquired and selected, and the NIST crosswalk maps it to privacy risk work. Without provenance records, teams cannot show the lawful basis, source or retention period for training and inference data. Keep a dataset register that records source, legal basis, collection date and any consent or license terms.
Writing DPIAs after deployment
Article 35 requires a DPIA before processing that is likely to be high risk, and automated evaluation with significant effects is named as an example. A DPIA written after launch cannot shape design choices such as data minimization or human review. Start the assessment during design, update it at each material change, and link it to the impact assessment records held under Annex A.5.
Unclear owners for automated decisions
Article 22 gives people the right not to be subject to decisions based solely on automated processing that significantly affects them. When no one owns the human review step, the organization cannot show that the decision is not solely automated. Assign a named owner for each automated decision, define when a human can override it, and log each review and appeal.
How DeployOpen prepares AI and privacy evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the records that support ISO/IEC 42001 controls and GDPR obligations for AI systems that process personal data are produced where the data lives. DeployOpen prepares systems, controls and evidence for assessment, while your organization owns its controls and an independent auditor or certification body issues any report or certificate.
How we scope
- Scope is agreed in writing before work starts, covering which AI systems, personal data flows and Annex A controls are in play.
- The written scope names the systems, data sources and evidence records to be produced for the ISO 42001 and GDPR work.
- Engagements are fixed-scope, and the scope document sets out who owns each control and each DPIA decision.
How we build
- Platforms are deployed in your cloud accounts, data centers or air-gapped networks, with access and logging configured from the start.
- Data acquisition, provenance and retention records are set up so that A.7 data documentation can be produced from system outputs.
- DPIA inputs such as processing descriptions, data flows and safeguard configurations are captured as the system is built, not reconstructed later.
How we hand over
- Deliverables include documented configurations, evidence records, and runbooks that your staff can operate without DeployOpen.
- Impact assessment and DPIA drafts are delivered for your DPO and AI governance owner to review, amend and approve.
- Evidence is organized so your internal auditor or an independent assessor can trace each claim to a configuration or log.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Security testing of AI systems and agents can be scheduled to produce evidence for risk and impact reviews.
- Your team confirms with the auditor, DPO or regulator which records they accept before scope is finalized.
