What Article 5(1)(d) bans and why it is hard to prove you are outside it
If your team has a model that scores people's likelihood of committing an offense, Article 5(1)(d) of the AI Act is the first test to run. The ban covers AI systems that assess or predict the risk of a natural person committing a criminal offense based solely on profiling or on assessing personality traits and characteristics. The exception covers tools that support a human assessment of a person's involvement in criminal activity that is already based on objective and verifiable facts directly linked to that activity. The risk the provision addresses is a decision about a person's future conduct made from what they are, not from what they have done. The prohibition reaches three moments: placing the system on the market, putting it into service, and using it. That means a provider who sells the model, a deployer who switches it on for a police unit, and an internal team that repurposes a pilot all fall within it. The prohibition has applied since 2 February 2025 under Article 113, so a system that is already running is not covered by a grace period. Confirm with counsel whether any prior use, testing or procurement step has already crossed one of these three moments.
The hard part is the line between "solely" and "supporting." A model that uses prior convictions, a dossier of verified facts about a specific incident, and a documented link to that incident may sit on the permitted side. A model that also weights neighborhood, age, employment history or inferred personality traits, and then produces a risk score that officers rely on, is much harder to defend. Ask the business owner which inputs drive the output, whether a human reviews the underlying facts before the score is used, and whether the reviewer can reject the score without penalty. Record those answers as evidence, because the burden of showing you are outside the ban sits with you. The related high-risk category matters even when the ban does not apply. Annex III point 6(d) classifies law enforcement AI that assesses the risk of offending or re-offending as high-risk where it is not based solely on profiling. Treat the question as two tests: first whether the prohibition is triggered, then whether the high-risk rules govern the system. Both answers need to be documented before procurement or deployment decisions are made.
Which systems, data and teams fall inside the ban
Article 5(1)(d) turns on a few scoping questions: what the output is, what the inputs are, who uses the result and who owns each decision. Each card below is a decision or check that can move a system inside or outside the prohibition, and each one needs a named owner before build work starts.
Is the output a risk score about a person
The first question is whether the system assesses or predicts the risk that a natural person will commit a criminal offense. A score about a location, a transaction pattern or a group of cases is not the same thing. Check the output field definitions, the unit of analysis and how downstream users read the result. A model that flags a named individual for criminal risk is in scope even if a human clicks the final button. Owner: data science with the product owner.
Inputs that are profiling or personality traits
The prohibition bites when the prediction rests solely on profiling or on assessing personality traits and characteristics. Map every input feature to its origin. Demographics, neighborhood, associations, psychometric or behavioral traits used alone point toward the ban. Document which features are excluded and test whether removing them changes the output. Owner: data science, with legal reviewing the feature list.
Objective facts linked to a specific offense
The exception covers AI that supports human assessment of a person's involvement in criminal activity that is already based on objective and verifiable facts directly linked to that activity. The test is the link between the fact and the criminal activity under review. Records of an identified offense or evidence tied to a particular case can qualify. General background data about a person does not. Ask legal to write down, for each input, the case fact it relates to.
Who uses the output: police, courts or private parties
Identify every user of the output, including police, prosecutors, courts, probation services and private parties acting for public authorities. Trace contracts and data flows, since a vendor tool used by a public body may still fall inside the scope. Confirm who sets thresholds and who receives alerts. Private operators can be caught where the output is used in the EU, so do not limit the review to public buyers. Owner: procurement and operations.
Third-party models and vendor tools
A vendor model, API or packaged product deployed in the EU is in scope for the deployer even when the provider sits outside the EU. Get written answers from the vendor on training data, feature sets, intended purpose and whether the tool produces individual risk predictions. Keep those answers in the procurement file. Where the vendor refuses to disclose inputs, treat that as a blocking risk until legal decides. Owner: procurement, with legal.
Logs and monitoring that prove the scope
Scope decisions need evidence that the running system matches the approved design. Keep logs of inputs categories, outputs, users and overrides for each prediction. Traces from an observability tool such as Langfuse can show which fields reached the model in a request, which helps confirm that profiling-only inputs were not used. Review logs on a fixed schedule and after any model or feature change. Owner: platform engineering, with the compliance lead.
How an assessor tests the criminal risk prediction ban
This table sets out each step an assessor or market surveillance authority is likely to take when testing whether a system predicts criminal risk from profiling alone. Read each row as a question the assessor asks, the evidence that answers it, and the finding that usually signals a problem. The main takeaway is that the ban turns on whether objective, case-linked facts drive the output, so documentation of inputs and human decision points matters as much as the model itself.
| Test step | What the assessor examines | Evidence requested | Common finding |
|---|---|---|---|
| Purpose and output review | Whether the system assesses or predicts the likelihood that a named person will commit a criminal offense, or whether it supports an assessment tied to a specific suspected act | Intended purpose statement, description of each output and its label, product documentation and marketing materials | Outputs described as risk scores for future offending with no link to a specific case |
| Input feature tracing | The source and meaning of every input feature, and whether each one records a verifiable fact about a specific investigation | Feature register with data source, collection basis and owner for each feature, and data lineage records | Undocumented features, or features that stand in for personality traits, residence, family background or social circle |
| Case-linkage test | Whether each output can be traced to objective and verifiable facts directly connected to the suspected criminal activity | Sample of outputs with the underlying case records, showing which facts the output relied on | Outputs produced for people with no recorded case facts, or outputs based on general profiles |
| Personality and profiling check | Whether the model uses personality traits, characteristics or profiling as the basis of the prediction | Model cards, training data descriptions, feature importance results and evaluation reports by subgroup | Model weights on proxies for personality or group membership that were not removed or justified |
| Human decision point review | Whether a trained person assesses the objective facts before any output affects a person, and whether that person can set the output aside | Written procedure for human review, reviewer training records, override logs and examples of rejected outputs | Outputs reaching case files or decisions with no recorded human assessment, or reviewers who cannot explain the facts behind a score |
| Usage log sampling | Whether actual use matches the documented purpose over time, including queries made outside the approved scope | Access logs, query logs and case reference records for a sample period selected by the assessor | Queries run on individuals with no case reference, or logs that are incomplete or cannot be linked to a case |
| Classification cross-check | Whether a system that falls under the ban was also assessed against the high-risk rules in Annex III point 6(d) where it is not based solely on profiling | Risk classification memo, Annex III analysis and conformity documentation where the system is high-risk | No classification analysis, or a high-risk claim made without the Annex III test being documented |
When a tool that supports human assessment stays outside the ban
The exception in Article 5(1)(d) keeps a tool outside the ban when it supports a human assessment of whether a person is involved in criminal activity that is already based on objective and verifiable facts directly linked to that activity. The test turns on the input, not the label. A tool that works from case-specific evidence, such as forensic results, documented transactions or witness records tied to a specific offense, can sit outside the prohibition. A tool that works from a person's profile, age, neighborhood, associates, personality traits or behavioral patterns cannot, because those inputs are not directly linked to a particular act that has already occurred. Organizations should map every input feature to a specific case file and ask whether the feature would still be available if the investigation had never been opened. If the answer is no, the feature is profiling, and the exception does not apply.
A defensible human decision step needs more than a person who clicks approve. The reviewing officer should receive the objective facts the tool used, see which of them were weighted and how, and be able to reach a different conclusion without penalty. The organization should log the reviewer's identity, the facts reviewed, the output shown, the decision taken and the reasons recorded, so that an assessor can reconstruct the decision. Ask the vendor or internal team to confirm whether the tool exposes its inputs and weights to the reviewer and whether overrides are recorded. Because the Act judges the system as deployed, a rubber-stamp workflow in which the score drives outcomes will weaken the exception even if the design looks compliant on paper.
The exception does not rescue a tool that estimates the general likelihood that a person will offend in the future. Predicting future offending from personality, history or profile is the conduct the prohibition targets, and no human review step converts it into a permitted tool. Separately, Annex III point 6(d) classifies law enforcement tools that assess the risk of offending or re-offending as high-risk where they are not based solely on profiling. Under the amended timeline, the high-risk obligations for Annex III systems apply from 2 December 2027, so a system placed on the market now that falls in that category should be planned against the full high-risk requirements. Confirm the current dates with the Commission's AI Act pages before you set a project plan.
How to establish that a system falls outside the prohibition
This sequence lets an organization show, with documented reasoning, whether an AI system that touches criminal risk is caught by the Article 5(1)(d) ban, covered by its exception, or a high-risk system under Annex III point 6(d). Each step ends with a record that an assessor or regulator can test.
Inventory the system and its stated purpose
Start by listing the system in the organization's AI inventory, with its owner, vendor or internal builder, the deployment context and the exact question the output answers. Write the purpose in terms of the decision it feeds, not the marketing description. Ask whether the output concerns a person's likelihood of committing a crime, the likelihood of re-offending, or involvement in an offense that has already occurred, because these lead to different routes. The output is a dated inventory entry that names the business owner and the decision point, and it is complete when a reviewer who has not seen the project can state what the system is for.
Document features and their provenance
List every input feature the model or scoring logic uses, such as case records, reports, behavioral data, demographic fields, or personality or psychometric measures. For each feature, record where it came from, who collected it, under what legal basis, and whether it records a verifiable event or an inferred trait. Flag any feature derived from profiling, questionnaires or assessed characteristics. The output is a feature register with a provenance column, and the step is closed when every feature has an entry and every inferred or trait-based feature is marked for review.
Classify outputs against the ban and the exception
Test each output against the two parts of Article 5(1)(d). The system falls within the prohibition if it assesses or predicts the risk that a natural person will commit a criminal offense based solely on profiling or on assessing personality traits and characteristics. It falls outside the ban if it supports a human assessment of a person's involvement in criminal activity that already rests on objective and verifiable facts directly linked to that activity. Mark each output as prohibited, excepted, or not applicable, with the reason written beside it. The output is a classification table, reviewed by someone who can explain the difference between prediction and assessment of an established fact.
Confirm the human decision step and its facts
Map how a person uses the output. Identify who makes the decision, what material they review besides the score, and whether they can reject or change the result. For the exception to hold, the human assessment must rest on objective, verifiable facts that tie directly to the alleged activity. Pull a sample of recent decisions and check whether the recorded basis cites those facts or only the score. The output is a decision-flow record and a sample review, and the step is closed when the team can show that the human decision depends on facts, not the score alone.
Decide whether the Annex III 6(d) route applies
Where the system is used by or for law enforcement to assess the risk of offending or re-offending, check Annex III point 6(d). Such a system is high-risk when it is not based solely on profiling. A system that falls outside the ban may still be high-risk, so this decision is separate from the prohibition result. Record whether the system is classified high-risk, which triggers the Chapter III requirements that apply from the dates set by the 2026 amendment, or whether it is outside Annex III on the stated facts. The output is a written high-risk determination with the Annex III reference cited.
Record the decision and obtain legal sign-off
Bring the inventory entry, feature register, classification table, decision-flow record and high-risk determination into one decision memo. State the conclusion for the prohibition and the high-risk route, the assumptions behind it, and the conditions that would change it, such as a new feature or a change in how the output is used. Legal counsel, the compliance lead and the business owner sign the memo, and it is re-opened whenever the system, its data or its use changes. Ask counsel to confirm the national law and the enforcement authority that apply in each Member State where the system is used. The output is a signed, versioned record that an independent assessor can review.
Evidence that shows the system is outside the ban
Article 5(1)(d) only protects a system that is not based solely on profiling or personality traits. The cards below are the records that let you show, to a regulator or assessor, which side of that line your system sits on. Most of them must be reviewed whenever the model, its data or its use changes, not just once at launch.
Written purpose statement
State what the system does, who uses its output, and the specific decision it informs. Name the criminal offense or activity it relates to, and say plainly that it does not predict whether a person will offend. Keep the statement tied to the use case in your deployment, not to the vendor's marketing. Review it whenever the scope, user group or decision it feeds changes, and record the date and approver of each version.
Feature inventory with data lineage
List every input the system uses, where each one comes from, and whether it is an objective, verifiable fact linked to a specific activity or a derived trait, score or behavioral inference. Trace each feature back to its source system and transformation steps. Any feature that describes personality or lifestyle without a factual link to an alleged offense weakens the exception, so flag it for removal or review. Refresh the inventory whenever a data source or feature is added.
Classification memo citing Article 5(1)(d)
Write a dated memo that states why the system falls outside the prohibition, quoting the exception's condition in your own words: support for human assessment of involvement in criminal activity already based on objective and verifiable facts. Address Annex III point 6(d) as well, since a system outside the ban may still be high-risk if it assesses offending or reoffending risk. Have legal counsel review the memo, and reopen it whenever the feature set or use changes.
Human decision procedure
Document who reviews each output, what facts they must confirm independently before acting, and which outputs they may not act on alone. Record the reviewer's authority to overrule the system and the steps for escalation. Keep sign-off logs showing that the human assessed the underlying facts, not only the score. Confirm the procedure against actual practice through periodic sampling, and update it when staffing or workflows change.
Training data documentation
Describe the datasets used to build or tune the system, including their origin, period, labeling method and known gaps. Show whether any training labels rely on personality assessments or profiling rather than verified case facts. Document data quality checks and bias testing. If a model provider supplies the model, request its training data documentation and confirm what your own fine-tuning added. Update this record each time the training data or model version changes.
Output logs and change records
Keep logs of each input-output pair, the reviewer's decision, and the model and configuration version in use at the time. Pair these with a change register that records every model update, feature change and configuration edit, with the reason and approver. Assessors test whether the human step is real by comparing logs with decisions. Set a retention period in your policy and confirm it meets your legal obligations, since log retention can also raise data protection questions.
What meeting Article 5(1)(d) costs in money and effort
This table breaks down the cost components of showing that an AI system does not predict criminal offending from profiling alone, who is paid for each one, and whether it is one-time or recurring. Use it to see where spend concentrates and what to request in a quote. Fines are shown as exposure, not as a budget line, because the Article 99(3) maximums apply to breaches rather than to compliance work.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Legal classification review | Internal counsel or external AI Act lawyers | One-time per system, repeated on material change | Number of use cases, whether the system touches law enforcement or judicial workflows, and how clearly the purpose is documented |
| Feature and data audit | Engineering and data science staff, or an implementation partner | One-time, then recurring with each model or feature change | Count of input features, whether personality traits or behavioral proxies appear, and whether training data is traceable |
| Engineering for logging and traceability | Platform engineers, typically on self-hosted observability tooling | Build cost one-time, running cost recurring | Request volume, retention periods, and how much of the decision path must be reconstructed for a regulator |
| Human-oversight and objective-fact controls | Operational staff and product owners | Recurring | Number of reviewers, the caseload per reviewer, and how often criteria are reviewed against verifiable records |
| Documentation upkeep | Compliance leads and system owners | Recurring, updated on each release | Release frequency, number of deployments, and how far documentation is automated from source systems |
| External legal or assessor review | Independent lawyers or assessors; only independent bodies issue reports | Usually one-time for the classification, recurring for periodic reviews | Scope of the written engagement, the jurisdictions involved, and whether a national authority has asked questions |
| Penalty exposure | Not a cost of compliance; borne by the undertaking if breached | Contingent | Article 99(3) sets fines of up to EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher |
Self-hosted tools that produce evidence for this ban
Langfuse, released under the MIT license, records observability data for LLM applications. Each trace captures every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, along with timing, inputs, outputs, token usage and metadata. For Article 5(1)(d), this matters when a system generates or supports a risk statement about an individual. A trace can show what data the system used, which retrieval steps supplied it, and which tool calls shaped the output, so the organization can demonstrate that a prediction was not driven solely by profiling or personality traits.
- Input and output capture: Records the prompt, retrieved context and generated output for each request, so reviewers can reconstruct a specific decision.
- Retrieval and tool steps: Shows which records, documents or external tools fed the output, which is where objective, verifiable facts would appear.
- Metadata tagging: Lets you attach a system identifier, model version and classification label to each trace so that evidence links back to the register.
- Retention and access: Confirm how long traces are kept, who can read them, and whether personal data in inputs is masked before storage.
- Coverage gaps: Traces only exist for instrumented code paths, so confirm that every route that reaches a person is instrumented.
Before relying on traces as evidence, confirm with your privacy team that storing inputs about individuals is lawful under your GDPR basis and retention policy, and test your self-hosted deployment for completeness.
garak, released under the Apache-2.0 license, is a scanner that probes language models for weaknesses such as hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. For this prohibition, it helps test whether a model or application can be pushed into producing unsupported criminal risk predictions about named or described individuals. It writes a JSONL report of every attempt and evaluation, plus a hit log listing the attempts that found a vulnerability. Those files are the record of what was tested, which is what an assessor will ask to see.
- Full attempt record: The JSONL report lists each probe, prompt and evaluation, so you can show the scope of testing rather than a summary claim.
- Hit log: Lists only the attempts that succeeded, which drives remediation tickets and re-test evidence.
- Custom probes: Confirm with the project documentation whether you can add probes that describe criminal-risk scenarios specific to your use case.
- Repeatable runs: Store the configuration and version used for each run so that results can be reproduced after a model change.
- Limits: A clean run shows that the probes did not succeed. It does not prove that no other route exists, so pair it with human red teaming and code review.
Garak is a scanner, not a compliance product. Confirm with your legal and security teams that the Apache-2.0 terms fit your internal use, and check the current project documentation before designing probes for your environment.
CISO Assistant, released under the AGPL-3.0-only license, is a governance platform that ships a large set of frameworks and runs audits and assessments against them. In this context, it can hold the register of AI systems, their classification decisions, the reasoning for each Article 5 screening, and the assessment records that link to traces and probe reports. The value is in keeping one traceable record for each system, which is what a market surveillance authority or auditor will request first.
- Classification register: Record each system, its intended purpose, its screening result against Article 5(1)(d) and its Annex III 6(d) status, with a dated rationale.
- Assessment records: Store the evidence owner, review date and outcome for each control or screening decision.
- Linked evidence: Attach references to trace exports, garak reports and approval records so the chain from decision to test result is visible.
- Framework mapping: The platform can map between frameworks, but treat any mapping as something to verify against the source text before relying on it.
- Licensing fit: AGPL-3.0-only has obligations if you modify and offer the software to others over a network. Confirm with counsel that your internal use and any changes fit your obligations.
Before adopting it, confirm the current release, hosting requirements and data protection terms with the project, and check that it can export records in a form your auditor accepts.
Where organizations fall short on this ban
Organizations rarely set out to build a crime predictor, but they often ship scoring tools that quietly rely on personality or background signals. The gaps below cluster around what a system uses as input, how humans use its output, and whether anyone can show the link between a score and objective case facts. Each card names a check and the action that closes it.
Proxy variables for personality or background
Models can reach personality traits or background characteristics through fields that look neutral, such as postcode, employment history, social contacts or school records. Article 5(1)(d) turns on whether the prediction rests solely on profiling or trait assessment. Review every feature with its owner, document why each one relates to objective facts about a specific offense, and remove features that only stand in for traits or background.
No record of objective case facts
The exception covers tools that support an assessment of involvement in criminal activity already based on objective and verifiable facts directly linked to that activity. Many teams cannot show which facts a given output relied on. Require each assessment request to reference the case file, the dated evidence items and the offense they concern, and reject requests that cite only profile data.
Human review that is a rubber stamp
A reviewer who approves every output without access to the underlying facts does not turn a profiling tool into a support tool. Auditors look for evidence that the reviewer could have overridden the result and did so in practice. Set review criteria, record the reviewer's reasoning for each decision, and sample overrides to confirm reviewers use them.
Missing logs linking outputs to inputs
Without traces that tie each score to its inputs, model version and reviewer, an organization cannot prove what the system did or defend a decision. Capture the input set, the model and prompt versions, the output, the human decision and timestamps for every run. Open-source observability tools such as Langfuse can record calls, inputs, outputs and metadata, but you must confirm they capture the data fields your case records need.
No re-check after model retraining
A retrained model can start to weight traits it previously ignored, so a tool that met the exception at launch may not meet it later. Treat each retraining as a change that requires a fresh review of features, test results and sample outputs. Keep a dated record of each version and the sign-off that allowed it into use.
Untested behavior under adversarial prompts
Where a language model supports risk assessment, its outputs can drift toward speculative judgments about people when prompts are unusual or inputs are incomplete. Test the system against prompts that invite personality-based conclusions and record the results. The open-source scanner garak can probe language models for several failure types and writes a report of each attempt, which you can use as one part of that testing record.
Questions buyers ask about the criminal risk prediction ban
Is a generic risk score that predicts criminal behavior banned under the AI Act?
A tool is banned under Article 5(1)(d) when it assesses or predicts the risk of a natural person committing a criminal offense based solely on profiling or on assessing personality traits and characteristics. The label on the score does not decide the question. What matters is the inputs and how the output is used. A generic score built only from demographic data, behavioral patterns or personality traits, and used to predict who will offend, falls inside the ban. Confirm the inputs with your legal and data teams before assuming a score is outside it.
Does the exception cover a case-management tool used by investigators?
It can, but only where the tool supports human assessment of a person's involvement in criminal activity that is already based on objective and verifiable facts directly linked to that activity. The question is whether the system relies on facts about the specific case or on a profile of the person. A tool that organizes evidence, timelines and documented facts for an investigator sits closer to the exception. A tool that ranks individuals by predicted future offending from profiling does not. Document how facts enter the workflow and where the human makes the judgment.
Are internal HR or fraud tools affected by this prohibition?
Only if they predict whether a person will commit a criminal offense based solely on profiling or personality traits. An HR tool that scores employees on attendance or performance is outside this article. A fraud model that flags transactions based on transaction behavior is generally about fraud detection, not predicting a person's criminal offending, but the answer depends on design. Where a fraud or insider-threat tool profiles individuals and labels them as likely offenders, legal review is needed. Other AI Act rules, including high-risk classification, may still apply to those tools.
What are the fines for breaching the criminal risk prediction ban?
Breaching a prohibition under Article 5 carries fines of up to EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, under Article 99(3) of the AI Act. The ban applies to placing on the market, putting into service and use, so both providers and deployers can be exposed. The fine ceiling is the same for every Article 5 prohibition, so the decision to rule a tool out early matters more than the specific article number.
What must our organization do itself, and what can a partner prepare?
The organization owns the decision. Its legal, compliance and business owners must classify each system, decide whether the exception applies, and accept the residual risk. Engineering teams must document the inputs, features and outputs of each system so that the classification can be tested. An implementation partner can help prepare the inventory, technical records and logging that show how a tool is used. Only an independent auditor, assessor or regulator reaches a formal conclusion about compliance. Ask any partner to state in writing which tasks it performs and which remain with your staff.
What evidence will an assessor ask for to test this prohibition?
An assessor will usually ask for the system inventory entry, a written purpose statement, the list of input data and features, and a rationale explaining why the system does not rely solely on profiling or personality traits. For tools claimed to fall under the exception, expect requests for records showing the objective, verifiable case facts the system uses and evidence that a human makes the assessment. Logs of inputs, outputs and user actions help show how the tool behaves in practice. Tools such as Langfuse can capture traces of model calls and tool steps, but you must confirm they capture what your assessment needs.
How long does it take to classify a system against this ban?
The time depends on how many systems you must review, how well they are documented, and whether the inputs are clear. A single tool with a written design and data list can be reviewed quickly. Systems that use opaque models, mixed data sources or vendor components take longer because the team must obtain facts from the supplier. Law enforcement and public-sector tools also need legal review. The prohibition has applied since 2 February 2025 under Article 113, so classification work is already time-sensitive. Agree a review scope and milestones in writing before you start.
How DeployOpen prepares evidence for this prohibition
DeployOpen helps organizations prepare the systems, records and evidence that show how an AI system relates to the Article 5(1)(d) ban on criminal risk prediction based solely on profiling. The organization keeps ownership of its classification decision, and an independent assessor reviews the evidence.
How we scope
- Engagements are fixed-scope, with the AI systems, data sources and decision points agreed in writing before work starts.
- The written scope states which tools are assessed for the profiling-only ban and which are assessed under the Annex III point 6(d) high-risk route.
- Ongoing support, testing and upgrades can be arranged as a retainer after the initial scope is delivered.
How we build
- We configure self-hosted systems so each risk assessment input, objective fact source and human review step is recorded.
- Logging of model inputs, outputs and human overrides is set up in the client's own infrastructure to support later review.
- Red teaming and security testing can probe whether a tool drifts into predicting offending from profiling alone.
How we hand over
- Deliverables include a written description of the system's decision logic, its data inputs and the human assessment step.
- Evidence packs map each claim about objective, verifiable facts to the records that support it, for the organization and its assessor.
- Handover covers runbooks and the documents the organization must keep as provider or deployer, with the organization retaining control.
How we support
- Support covers periodic reviews of the system's inputs when the organization changes its data sources or use cases.
- Changes to the classification rationale are documented so the evidence trail stays current over time.
- Questions about whether an independent assessor or legal counsel should review a specific design are referred to those parties.
