The proof behind every answer.

• UnverifiedNotify incidents if designated

  If designated as a critical entity, notify the competent authority without undue delay of incidents that significantly disrupt or have the potential to significantly disrupt the provision of essential services.

  No code evidence yet
• UnverifiedTake resilience measures if designated

  If designated as a critical entity, carry out a risk assessment and take appropriate and proportionate technical, security, and organisational measures to ensure resilience, including physical protection, continuity, and incident handling.

  No code evidence yet
• UnverifiedDetermine critical-entity applicability

  Determine whether the organisation is a critical entity within a CER essential sector as designated by a Member State; the resilience obligations apply only to entities so designated for providing an essential service above the relevant threshold.

  No code evidence yet

• PlannedConformity assessment, EU declaration, and CE marking

  Carry out the applicable conformity assessment, draw up the EU declaration of conformity, and affix the CE marking before placing an in-scope product on the market.

  No code evidence yet
• UnverifiedMaintain technical documentation

  Draw up and keep current the technical documentation demonstrating the product meets the essential cybersecurity requirements, including the risk assessment and vulnerability-handling processes.

  No code evidence yet
• PartialProtect confidentiality and integrity of data

  Protect the confidentiality and integrity of stored, transmitted, and processed data through encryption and access controls, and process only data adequate and relevant to the product's function (data minimisation).

  EvidenceCode
• PartialSecure by design and secure by default

  Design, develop, and produce the product so it is secure by design and delivered in a secure-by-default configuration: minimal attack surface, least functionality enabled by default, and protection against unauthorised access.

  EvidenceCode
• PartialReport actively exploited vulnerabilities and severe incidents

  Report actively exploited vulnerabilities and severe incidents affecting an in-scope product’s security to the CSIRT of main establishment (Denmark: CFCS) and ENISA via the single reporting platform: early warning within 24 hours, notification within 72 hours, and a final report within 14 days of a corrective measure being available (exploited vulnerability) or 1 month (severe incident), with an intermediate report on request. Inform impacted users of the vulnerability or incident and the mitigations they can deploy, in a structured machine-readable format where appropriate (Art 14(8)); this is a duty in its own right, not a consequence of the regulator notification. Scope attaches by product surface: the desktop client (with the backend functionality it cannot work without, which is that product’s remote data processing solution) and any distributed SDK or package supplied commercially; the bare hosted SaaS is not a product with digital elements, and non-monetized FOSS (partial-content) is exempt while it stays non-monetized.

  EvidenceArtifact
• ImplementedCoordinated vulnerability disclosure policy

  Put in place and enforce a coordinated vulnerability disclosure policy with a single point of contact, so reporters can disclose vulnerabilities responsibly and receive a coordinated response.

  EvidenceArtifact
• UnverifiedProvide security updates over the support period

  Provide security updates that remediate vulnerabilities during the product's support period, free of charge and, where feasible, separately from feature updates, with clear information to users.

  No code evidence yet
• ImplementedIdentify and document components (SBOM)

  Identify and document the components contained in the product, including through a software bill of materials in a commonly used, machine-readable format, so vulnerable components can be found and tracked.

  EvidenceGate
• PartialMonitor upstream components for advisories and record each decision

  Continuously monitor the components the product depends on for newly disclosed vulnerabilities and upstream changes that affect them, decide on each finding (remediate, schedule, accept the risk with a stated reason), and keep a record of when the sources were consulted, what they returned against the shipped versions, what was decided and by which role, so the handling process is demonstrable and not merely asserted.

  EvidenceGate
• ImplementedIdentify and address vulnerabilities without delay

  Operate a process to identify and address vulnerabilities in the product and its components without delay, including regular testing and remediation, so no product ships with a known exploitable vulnerability.

  EvidenceGate

• PartialCompare only products that meet the same needs or serve the same purpose

  The comparison must be between goods or services meeting the same needs or intended for the same purpose (art_4 point b). A comparison page states the category it compares within, and a product that serves a different purpose is not placed in the table to make ours look complete.

  EvidenceTest
• ImplementedMake no comparison that is misleading about either product

  A comparison is permitted only if it is not misleading within the meaning of art_2, art_3 and art_8 of this directive or of the misleading-action and misleading-omission rules of the UCPD (art_4 point a). Misleading advertising is any advertising that in any way, including its presentation, deceives or is likely to deceive those it reaches and is likely to affect their economic behaviour or injure a competitor (art_2), assessed on all its features and in particular the characteristics, price and attributes it states (art_3).

  EvidenceTest
• PartialNeither discredit the competitor nor trade on its marks

  The comparison must not discredit or denigrate the competitor's marks, names, goods, services, activities or circumstances (art_4 point d), must not take unfair advantage of the reputation of the competitor's marks or names (art_4 point f), must not present the product as an imitation or replica of a product bearing a protected mark (art_4 point g), and must not create confusion between the advertiser and the competitor or between their marks, goods or services (art_4 point h).

  EvidenceTest
• ImplementedCompare material, relevant, verifiable and representative features, objectively

  The comparison must objectively compare one or more material, relevant, verifiable and representative features of the products, which may include price (art_4 point c). A cell is a fact a reader can check against a public source, never an adjective, an opinion or a score the advertiser assigned; a feature is chosen because a buyer decides on it, not because the advertiser wins it.

  EvidenceTest
• ImplementedKeep every comparison current, because cessation needs no proof of loss

  Member States give competitors and bodies with a legitimate interest the means to obtain an order for the cessation of unlawful comparative advertising, or its prohibition before publication, without proof of actual loss, intention or negligence, under an accelerated procedure with interim or definitive effect (art_5). A comparison is therefore only as lawful as its currency: the compared fact is owned by the competitor, who can change it without notice.

  EvidenceGate
• ImplementedTreat any sentence that identifies another product as comparative advertising

  Advertising is the making of a representation in any form in connection with a trade to promote the supply of goods or services, and comparative advertising is any advertising which explicitly or by implication identifies a competitor or goods or services offered by a competitor (art_2). The conditions of art_4 therefore attach to a sentence the moment it names or alludes to another product, wherever on the site it sits.

  EvidenceGate

• UnverifiedMonitor the certification framework for a relevant or mandatory scheme

  Track the European cybersecurity certification framework for a scheme relevant to our category (notably the EUCS cloud-services scheme) and for any Union or national law that makes such a scheme mandatory, since certification is otherwise voluntary.

  No code evidence yet
• UnverifiedUnderstand the basic-level self-assessment route

  For a scheme at the 'basic' assurance level covering low-risk services, understand that conformity self-assessment under the provider's own responsibility is permitted, allowing an EU statement of conformity to be issued without a third-party certificate.

  No code evidence yet
• PartialPublish supplementary cybersecurity information if certified

  If a product/service is certified or an EU statement of conformity is issued, publish the supplementary cybersecurity information: secure configuration/operation guidance, the period during which security support is offered, and a contact for receiving vulnerability reports.

  EvidenceCode
• PartialHold the security objectives a certification scheme would require

  Be able to demonstrate the security objectives that European cybersecurity certification schemes require: protecting stored/transmitted/processed data against unauthorised access or disclosure throughout the lifecycle, access control, resilience/availability, secure-by-default configuration, and vulnerability handling.

  EvidenceArtifact

• UnverifiedNotify and meet neutrality conditions if providing intermediation

  If providing data intermediation services, notify the competent authority before starting, and meet the structural conditions, in particular neutrality: the intermediary must not use the intermediated data for its own purposes and must keep intermediation structurally separate from other services.

  No code evidence yet
• UnverifiedDetermine data-intermediation / altruism applicability

  Determine whether the service constitutes a data intermediation service, a data altruism organisation, or a re-user of protected public-sector data; the DGA's structural and notification duties attach only to those activities.

  No code evidence yet
• PartialSafeguard protected data against unlawful international transfer

  Where handling protected categories of data covered by the DGA, take measures to prevent unlawful international transfer of or governmental access to that data.

  EvidenceCode

• UnverifiedICT governance and accountability

  Maintain clear governance for ICT resilience: defined roles, management accountability for ICT risk, and documented policies. As a provider we must be able to evidence this to financial customers assessing us under their own DORA framework.

  No code evidence yet
• PartialAnomalous-activity detection

  Detect anomalous activity and ICT incidents promptly: monitoring, logging, alerting with thresholds that surface breaches and performance anomalies fast enough to meet reporting clocks.

  EvidenceCode
• PartialProtection and prevention controls

  Implement security controls that protect ICT systems and data from compromise: access control, encryption, network security, secure configuration. Overlaps NIS2 Art 21 and GDPR Art 32; one control set can satisfy all three.

  EvidenceCode
• UnverifiedResponse, recovery, and backup

  Maintain response-and-recovery procedures and backup policies with tested restoration: defined RTO/RPO, backups isolated from the primary, and periodic restore tests. Cover the primary DB, object storage, and the vector index.

  No code evidence yet
• PartialClassify and report major incidents to customers

  Classify ICT incidents by DORA criteria and, as a provider, notify affected financial customers of major incidents fast enough for them to meet their own regulatory reporting deadlines. Provide the data they need to report to competent authorities.

  EvidenceArtifact
• PartialICT incident management process

  Run a defined ICT-incident management process: detect, log, classify, and manage incidents to resolution with a clear internal workflow and roles.

  EvidenceArtifact
• UnverifiedCyber-threat information sharing (optional)

  Optionally participate in trusted cyber-threat-intelligence information-sharing arrangements, within data-protection limits, to strengthen collective resilience.

  No code evidence yet
• UnverifiedSupport digital operational resilience testing

  Enable and support resilience testing: vulnerability assessment and testing of ICT tools/systems, and cooperation with customers' threat-led penetration testing where our service is in scope.

  No code evidence yet
• UnverifiedSubcontracting and concentration-risk transparency

  Disclose the chain of subcontractors that support the service (model/embedding providers, storage, connectors) so financial customers can assess ICT concentration risk, and control material subcontracting changes.

  No code evidence yet
• PlannedDORA Art 30 contractual provisions

  Contracts with financial customers must carry the Art 30 provisions: service descriptions and SLAs, data location, access/audit/inspection rights, incident cooperation, subcontracting conditions, and exit/termination assistance. Our standard terms must support these.

  No code evidence yet

• ImplementedLet anyone notify allegedly illegal content

  Provide an easy, electronic notice mechanism for any individual or entity to report specific allegedly illegal content, confirm receipt, decide in a timely, diligent, non-arbitrary and objective manner, and tell the notifier the outcome and the redress available.

  Known limit: A failed notification mail is not retried automatically.

  EvidenceArtifact
• ImplementedReport suspected threats to life or safety

  Promptly inform the competent law-enforcement or judicial authorities when information gives rise to a suspicion of a criminal offence involving a threat to the life or safety of persons.

  EvidenceArtifact
• ImplementedGive a statement of reasons for every restriction

  When restricting content, an account, or payments because content is illegal or breaches the terms, give the affected user a clear and specific statement of reasons: the measure, the facts, whether automation was used, the legal or contractual ground, and the redress available.

  Known limit: A failed notification mail is not retried automatically.

  EvidenceArtifact
• UnverifiedClassify the service: hosting service, not an online platform

  Determine the intermediary-service tier, since the due-diligence duties stack by tier: every intermediary service, then hosting services, then online platforms, then very large platforms.

  No code evidence yet
• ImplementedPublish single points of contact for authorities and for users

  Designate and publish an electronic single point of contact for Member State authorities, the Commission and the Board, and one for recipients of the service that is not solely automated, stating the languages it handles.

  EvidenceArtifact
• ImplementedState usage restrictions and moderation in the terms

  Include in the terms and conditions, in clear and plain language, any restrictions on use of the service, including the policies, procedures, measures and tools used for content moderation and the internal complaint handling.

  Known limit: The translated terms have no clause-by-clause legal review.

  EvidenceTest
• UnverifiedAnnual transparency report, exempt while a micro or small enterprise

  Publish an annual machine-readable report on content moderation; providers that are micro or small enterprises and not very large online platforms are exempt.

  No code evidence yet

• PartialUse open, documented formats for exported data

  Support the essential interoperability requirements by exporting data using open interoperability specifications or documented, commonly used formats, so that switched data remains usable and, where relevant, services can be used in parallel.

  No code evidence yet
• PartialExport customer data in a structured, common, machine-readable format

  On switching or termination, make the customer's exportable data and digital assets available in a structured, commonly used, and machine-readable format so the data can be ported to another service.

  EvidenceCode
• PartialSafeguard against unlawful third-country governmental access

  Take adequate technical, organisational, and legal measures to prevent international and third-country governmental access to, or transfer of, non-personal data held in the Union where such access would conflict with Union or national law.

  EvidenceCode
• UnverifiedRemove switching and data-egress charges

  Do not impose switching charges on customers for changing provider; from 12 January 2027 switching charges must be withdrawn, and only cost-based data-egress charges are permitted during any transition period as allowed by the Act.

  No code evidence yet
• UnverifiedEnable customers to switch or terminate the service

  Remove pre-commercial, commercial, technical, contractual, and organisational obstacles that prevent a customer from switching to another provider or to on-premises infrastructure, including defined maximum notice and transition periods and provider assistance during the switch.

  No code evidence yet
• PartialPublish where customer data is processed and stored

  Make available up-to-date information about the jurisdiction(s) in which the infrastructure used to process the customer's data is located, so customers can assess international-access exposure.

  EvidenceCode

• PartialDesign and provide the service to the accessibility requirements

  Where in scope, design and provide the service in accordance with the accessibility requirements of Annex I (Sections III/IV), so the service is perceivable, operable, understandable, and robust for persons with disabilities, and keep procedures so it stays conformant as the service changes.

  EvidenceGate
• UnverifiedDocument any disproportionate-burden or fundamental-alteration claim

  If relying on the exemption that compliance would require a fundamental alteration or impose a disproportionate burden, carry out and document the assessment against the Annex VI criteria, keep it for five years, renew it on service change and at least every five years, and notify the competent authority. Funding received specifically to improve accessibility disqualifies the disproportionate-burden claim.

  No code evidence yet
• PartialMeet the harmonised standard once it is cited, for presumption of conformity

  Conformity with harmonised standards whose references are published in the Official Journal confers a presumption of conformity with the EAA accessibility requirements, but only for a version cited under this Directive. No version of EN 301 549 is cited under the EAA yet (v3.2.1 is cited under the Web Accessibility Directive only), so the route today is to meet the Annex I requirements directly and target the version expected to be cited: EN 301 549 v4.1.1, whose web clauses map to WCAG 2.2 AA.

  EvidenceGate
• PartialPublish an accessibility statement (how the service meets the requirements)

  Prepare and make publicly available, in accessible written and oral formats, the information required by Annex V explaining how the service meets the applicable accessibility requirements, and keep it current for as long as the service operates.

  EvidenceCode
• UnverifiedDetermine EAA scope and the microenterprise service-provider exemption

  Establish whether, and which parts of, the offering fall under the EAA. It applies to services provided to consumers (natural persons outside their trade/business), including e-commerce services; services provided solely to businesses for professional use are outside that consumer scope. Microenterprise service providers are exempt from the service accessibility requirements. Record the determination, because scope changes when the company grows past microenterprise size or exposes a consumer-facing e-commerce/signup surface.

  No code evidence yet

• PartialEnsure accuracy, robustness and cybersecurity (Art 15)

  For high-risk systems, achieve appropriate accuracy, robustness and cybersecurity, including resilience to adversarial inputs. For our platform this maps directly to prompt-injection and indirect-injection defenses on the RAG/copilot surface and to retrieval-quality monitoring.

  No code evidence yet
• UnverifiedData and data governance for high-risk (Art 10)

  If high-risk, apply data governance to training/validation/testing data: relevance, representativeness, error-checking, and bias examination. For a RAG system this extends to the curation and provenance of the indexed corpus.

  No code evidence yet
• ImplementedPromote a sufficient level of AI literacy in staff operating the AI system

  Take measures to promote a sufficient level of AI literacy (technical knowledge, the context the system is used in, and its limits) in staff and other persons operating or using the AI system on our behalf. Binds providers AND deployers of ANY AI system regardless of risk tier; applied since 2 Feb 2025. The Digital Omnibus on AI (in force Jul 2026) softened Art 4 from an obligation of result (ensure) to an obligation of effort (promote); mandatory human-oversight training for HIGH-RISK deployers is carved out and remains binding. Pre-Omnibus 'ensure' phrasing is stale and must not be cited in new copy.

  EvidenceArtifact
• UnverifiedDeployer obligations for high-risk use (Art 26)

  As a deployer of a high-risk system, follow the provider's instructions, assign competent human oversight, monitor operation, keep logs, and inform affected persons where required. Where we deploy on a customer's behalf, delineate who is the deployer.

  No code evidence yet
• UnverifiedConsume upstream GPAI provider documentation

  As a downstream integrator of general-purpose AI models, obtain and retain the Art 53 technical documentation and usage information the GPAI provider must supply, and respect their acceptable-use and copyright terms. We are not a GPAI provider ourselves.

  No code evidence yet
• UnverifiedDesign for human oversight (Art 14)

  For high-risk deployment, ensure the system can be effectively overseen by humans: outputs are reviewable, the assistant is decision-support not autonomous action, and a human can disregard or reverse its output.

  No code evidence yet
• UnverifiedFundamental-rights impact assessment (Art 27)

  Certain high-risk deployers (public bodies, essential-service providers) must complete a fundamental-rights impact assessment before use. Provide the inputs (system purpose, affected groups, risks) needed for a customer to complete theirs.

  No code evidence yet
• UnverifiedRegistration and post-market monitoring (Art 49, 72)

  If we become a provider of a high-risk system, register it in the EU database (Art 49) and run a post-market monitoring plan (Art 72) that collects performance/incident data and feeds corrective action.

  No code evidence yet
• PartialNever implement prohibited AI practices

  The product must never do any Art 5 practice: subliminal/manipulative techniques causing harm, exploiting vulnerabilities, social scoring, untargeted facial-image scraping, emotion inference in workplace/education, or biometric categorisation of sensitive traits. This is an absolute design constraint, not risk-tiered.

  No code evidence yet
• UnverifiedProvide instructions and information to deployers (Art 13)

  If we are a provider of a high-risk system, supply deployers with clear instructions for use: capabilities, limitations, intended purpose, human-oversight measures, and expected accuracy, so they can use it lawfully.

  No code evidence yet
• PartialAutomatic record-keeping / logging (Art 12)

  High-risk systems must automatically log events over their lifetime to enable traceability. For us: retain query/response and retrieval-decision logs sufficient to reconstruct behaviour, within GDPR retention limits.

  EvidenceCode
• UnverifiedClassify the system's risk tier and record it

  Formally classify the assistant against Annex III. A general document-search/chat copilot is limited-risk (Art 50 only); it becomes high-risk if marketed for an Annex III use (e.g. employment screening, creditworthiness, essential services). Record the classification and re-run it when features or target verticals change.

  No code evidence yet
• PartialMark AI-generated content (Art 50)

  AI-generated or manipulated output (text, images, audio) must be marked as artificially generated in a machine-readable way where feasible, so downstream consumers and users are not misled about provenance. Exemption currency (final Guidelines, adopted 20 Jul 2026): standard/assistive editing now expressly includes machine translation (summaries and substantive rewrites still require marking), and a narrow B2B/industrial carve-out applies only when three cumulative conditions are met (strictly technical output; a limited pre-defined professional audience inside the organisation; no intended external sharing plus safeguards against foreseeable misuse). Transitional: systems on the market before 2 Aug 2026 have until 2 Dec 2026 for this marking duty only (Digital Omnibus, not Art 50 itself).

  EvidenceTest
• PartialDisclose AI interaction to users (Art 50)

  Users must be informed they are interacting with an AI system unless it is obvious. This applies regardless of risk tier. The chat surface must make the AI nature clear at first contact.

  EvidenceCode
• UnverifiedSupport the right to explanation (Art 86)

  A person subject to a high-risk-AI-assisted decision with significant effect has the right to a meaningful explanation of the role the AI played. Retain enough context (retrieved sources, decision rationale) to explain an individual output.

  No code evidence yet
• UnverifiedDetermine and manage our AI-value-chain role

  Establish whether we are a deployer, a provider, or both. Putting the assistant on the market under our name, or substantially modifying a third-party model, makes us a provider with the corresponding obligations (Art 25). Track this per feature.

  No code evidence yet

• ImplementedSupport data-subject access and erasure

  Enable the controller to fulfil data-subject rights of access and erasure, by providing the ability to retrieve a data subject's personal data and to delete it across all stores on request.

  EvidenceTest
• PartialMaintain records of processing activities

  Maintain a record of processing activities, and as a processor maintain a record of all categories of processing carried out on behalf of a controller, available to the supervisor on request.

  No code evidence yet
• UnverifiedSupport EU-institution customers as an EUDPR processor

  Recognise that when an EU institution or body is the customer, that institution is the controller under the EUDPR and Nordvec is its processor; provide processing under the controller's documented instructions with GDPR-equivalent safeguards and a data processing agreement.

  No code evidence yet
• PartialApply appropriate security of processing

  Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate encryption and measures ensuring confidentiality, integrity, availability, and resilience of processing systems.

  EvidenceCode
• PartialRestrict international transfers to lawful bases

  Transfer personal data to a third country or international organisation only on the basis of an adequacy decision or appropriate safeguards, so processing remains protected.

  EvidenceCode

• ImplementedGive the controller the technical facts it needs for its DPIA and works-council process

  Under Art 28(3)(f), provide accurate technical documentation of what a connected source ingests, how it is retained, and who can query it, so the controller can conduct its own Art 35 DPIA and satisfy its works-council or CSE documentation duty. The vendor supplies inputs; the controller owns the assessment.

  EvidenceArtifact
• UnverifiedDesign org-wide connection as a deliberate, acknowledged administrator action

  Where a source can be promoted to organization-wide (making employee content searchable across the tenant), design it as a deliberate administrator action with explicit opt-in and an audit-logged acknowledgement that any required works-council or CSE step is complete, so the controller's labour-law step is recorded before the data is broadly exposed.

  No code evidence yet
• PartialOffer minimization levers the controller can invoke to keep its assessment defensible

  Offer data-minimization controls (excluding personal uploads, per-source scoping, excluding private/direct messages) so the controller can narrow what an employee-comms source exposes and keep its own proportionality assessment defensible. The vendor cannot decide minimization for the controller; it must offer the lever.

  EvidenceArtifact
• ImplementedAllocate employment-law compliance to the controller in the DPA and name the instruments

  The data processing agreement must state that employment and labour-law compliance is the controller's responsibility when it connects organization-wide sources that make employee content AI-searchable, naming the concrete national duties (works-council co-determination, CSE consultation) and the employee-monitoring notices, so the allocation is explicit and not assumed.

  EvidenceArtifact
• ImplementedProcess connected employee data only on documented controller instruction

  Employee data reached through a connected source is processed only on the controller's documented instruction (Art 28(3)(a)); the vendor does not repurpose it for its own ends, and the controller's active use of an integration is the complete instruction.

  EvidenceArtifact
• PartialProvide in-product transparency surfaces and an admin compliance kill-switch

  Provide the in-product surfaces a controller needs to inform its workforce (Art 13/14 enablement) and an administrator control to disable a feature where a works-council or minimization duty requires it, so the controller can operate its own transparency and co-determination obligations.

  EvidenceTest

• PartialDemonstrate controller accountability

  Be able to demonstrate compliance: policies, this obligations register with implementation status, audit logs, and evidence trails that an enterprise or SOC 2/ISO auditor can inspect.

  No code evidence yet
• PartialData protection by design and by default

  Bake data minimisation, purpose limitation, and privacy defaults into features: collect only what a purpose needs, default to the least-exposing setting, and pseudonymise where feasible (e.g. no PII in logs, per Project Rule 11).

  No code evidence yet
• UnverifiedRun a DPIA for high-risk processing

  Where processing is likely high-risk (large-scale profiling, systematic monitoring, special-category data in documents), complete a data protection impact assessment before deployment and revisit on material change.

  No code evidence yet
• PartialAssess and document whether a Data Protection Officer must be designated

  Determine whether Art 37(1)(b) applies (core activities consisting of regular and systematic monitoring of data subjects on a large scale) and either designate a DPO or record the reasoned determination that none is required. Enterprise procurement asks for this determination either way.

  No code evidence yet
• ImplementedSynthetic or anonymised data outside production

  Development, test, evaluation and preview environments run on synthetic or anonymised data. Production personal data enters them only under a recorded, approved, time-boxed exception, closed by deletion. A copy in a non-production environment is the same personal data under weaker controls: outside the production access model, outside its retention schedule, and outside its erasure path, so an Art 17 request deletes the production rows and the copy survives.

  Known limit: The check reads the repository, not a running database.

  EvidenceArtifact
• ImplementedMaintain records of processing activities (ROPA)

  Keep a record of processing activities: purposes, categories of data and subjects, recipients, transfers, retention, and security measures. This distillation is a machine-readable seed for that record.

  EvidenceArtifact
• UnverifiedConstrain solely-automated decisions

  Do not make decisions with legal/similarly-significant effect based solely on automated processing without a lawful exception; where AI output drives such a decision, provide human review and contest paths.

  No code evidence yet
• PartialCommunicate erasure and rectification to every recipient

  When personal data is rectified or erased, communicate that change to each recipient to whom the data was disclosed, unless doing so proves impossible or involves disproportionate effort, and be able to tell the data subject who those recipients are if they ask. For this platform the recipient classes are subprocessors that held copies (embedding provider, object storage, email vendor, error telemetry) and tenant-configured webhook endpoints that received document/event payloads.

  No code evidence yet
• PlannedSuspend erasure under a legal hold, fail-closed

  Where personal data must be retained to comply with a legal obligation or for the establishment, exercise, or defence of legal claims, suspend erasure of exactly that data for the duration of the hold, evaluate the hold before any deletion begins, and treat a missing or unreadable hold record as blocking (fail-closed), never as permission to proceed.

  No code evidence yet
• ImplementedFulfil right of access (export of a data subject's data)

  On request, produce all personal data held about a data subject across primary store, document chunks, embeddings, chat history, and logs, plus the metadata in Art 15 (purposes, recipients, retention, source), within one month.

  EvidenceTest
• PartialFulfil right to erasure across all stores

  On an erasure request, hard-delete a data subject's personal data across primary DB, document chunks, embeddings/vector index, chat history, caches, and backups (or document backup-rotation exclusion), within the SLA, and log the erasure with an audit trail including failures.

  EvidenceTest
• PartialHonour objection to processing

  Allow a data subject to object to processing based on legitimate interests (and unconditionally to direct marketing), and stop the processing unless compelling legitimate grounds are documented.

  EvidenceTest
• ImplementedFulfil right to data portability

  Export the data subject's provided data in a structured, commonly-used, machine-readable format (e.g. JSON) where processing is by consent or contract and automated.

  EvidenceTest
• PartialFulfil right to rectification

  Allow correction of inaccurate personal data and propagate it to derived artifacts: re-index the affected documents and re-embed so stale text does not persist in retrieval.

  EvidenceTest
• PartialFulfil right to restriction of processing

  Support a restriction flag that suspends processing (exclude the data from retrieval/embedding/analytics) while retaining storage, without deleting, and reversible.

  EvidenceTest
• PartialDocument whether the service is offered to children and gate consent accordingly

  Where an information society service is offered directly to a child and relies on consent, Art 8 requires parental consent below the applicable age (13 in Denmark, up to 16 in other member states). Determine and record whether the B2C self-serve motion is offered to children, and add age assurance if it ever is.

  No code evidence yet
• ImplementedCapture and allow withdrawal of consent

  Where consent is the basis (e.g. optional AI features, marketing), capture it as a freely-given, specific, unambiguous, logged action, and make withdrawal as easy as giving it. Withdrawal must stop the dependent processing.

  EvidenceArtifact
• UnverifiedRecord a lawful basis per processing purpose

  Every processing purpose (document indexing, embedding, chat, connector sync, analytics) must be tied to a stored lawful basis per tenant. Do not process personal data for a purpose that lacks a recorded basis.

  No code evidence yet
• PartialBind processors and subprocessors

  Every subprocessor (LLM/embedding providers, object storage, hosting, email, error telemetry) must be under an Art 28 data processing agreement, listed in the notice, and offer sufficient guarantees. Maintain a current subprocessor list. Connector sources are brought by the user, who authorises reads of their own data: they process for the user, not for us, and are recorded as sources in the Art 30 register rather than as subprocessors.

  EvidenceCode
• PlannedReturn or delete all personal data on contract termination

  On termination of processing services, at the controller's choice, return or delete all personal data processed on the controller's behalf and delete existing copies, unless retention is legally required. For a multi-tenant controller this is the whole-tenant offboarding deliverable, a distinct duty from an individual data subject's erasure request.

  No code evidence yet
• PartialEnforce storage limitation and retention

  Do not keep personal data longer than the purpose needs. Enforce per-tenant retention that expires chat history, ingested documents, and derived embeddings/logs on schedule, and delete on account closure.

  EvidenceCode
• PartialDetect and notify personal data breaches

  Detect breaches, notify the supervisory authority within 72 hours where risk arises, and inform affected data subjects when the risk is high. Maintain an internal breach register regardless of notifiability.

  EvidenceArtifact
• PartialContinuously assure access-control enforcement

  Do not rely on a one-time test that access control works; exercise the enforcement paths on a schedule in production and alert on any access that should not occur, so a regression is caught in operation rather than only at build time.

  EvidenceTest
• ImplementedScope ingestion credentials to least privilege

  Prevent an automated ingestion credential from broadening a restricted document to organisation-wide visibility. Widening a previously-restricted document must require a separate, elevated authority and must be recorded as a privileged action.

  EvidenceAssessed
• ImplementedEnforce document permissions at query time

  Evaluate document-level access against live permissions on every retrieval, so a revoked share or an erased principal is excluded from the very next query. Enforcement must not depend on a periodically synchronised copy of permissions.

  EvidenceTest
• ImplementedResolve group access at query time

  Resolve group and nested-group membership at query time from live data rather than pre-expanding it into a stored copy, so document access always reflects the current group structure and a membership change cannot leave stale access behind.

  EvidenceTest
• ImplementedApply appropriate technical + organisational security

  Encrypt personal data in transit and at rest, enforce least privilege, and maintain confidentiality, integrity, availability and resilience proportionate to risk (Art 32). Cover the vector store and object storage, not just the primary DB.

  Known limit: A database timing side channel is an accepted residual risk, with compensating controls.

  EvidenceArtifact
• ImplementedEnforce tenant isolation as a security measure

  Guarantee one tenant's personal data can never surface in another tenant's retrieval, chat, or exports. Isolation must hold at the row level and in the vector search path.

  EvidenceAssessed
• PartialAttribute customer-directed transfers (webhook destinations) correctly

  When the customer (data controller) registers an outbound delivery destination (a webhook endpoint URL) that resolves outside the EU/EEA, the transmission satisfies the EDPB Guidelines 05/2021 three cumulative transfer criteria and is a Chapter V transfer that the processor executes on the controller's documented instruction (Art 28(3)(a): the registration itself is the instruction). The lawful-basis responsibility under Art 44-49 for that destination sits with the controller who chose it, not with the processor's subprocessor selection. The processor's duties are: transmit only on the documented instruction, minimise the transferred surface (Art 5(1)(c): identifiers, counts and timestamps, never content), and record the responsibility split contractually in the DPA. This is the controller-instructed-destination angle; the vendor-selection angle is covered by eu-data-residency.

  EvidenceArtifact
• PartialKeep personal data in the EU / lawful-transfer only

  Keep all user personal data in EU regions. Any processing that would leave the EU/EEA needs an Art 44-49 basis (adequacy or safeguards). Prefer EU-region model/embedding/storage endpoints to avoid transfers entirely.

  EvidenceCode
• UnverifiedState the AI processing of personal data in the privacy notice

  Where personal data is processed by the AI features (prompts, retrieved documents, memories, generated output), the privacy notice states that processing with its purposes and legal basis in the concise, intelligible form Art 12 requires, and, where any of it amounts to automated decision-making within Art 22, its existence and the logic involved (Art 13(2)(f) on direct collection, Art 14(2)(g) on indirect). Telling a person they are interacting with an AI system, and marking generated output, are EU AI Act Art 50 duties, not GDPR ones; they are tracked in the eu-ai-act distillation and only cross-referenced here.

  No code evidence yet
• PartialServe a transparent privacy notice

  Present the Art 13/14 information (identity, purposes, legal basis, recipients incl. subprocessors and any non-EU transfer, retention, rights) in the user's language, concise and accessible, before or at collection.

  EvidenceCode

• UnverifiedManagement accountability for cybersecurity

  Management must approve the cybersecurity risk-management measures, oversee their implementation, and receive training. Cyber risk is a board-level, documented responsibility, not solely an engineering concern.

  No code evidence yet
• PartialReport significant incidents on the NIS2 clock

  For a significant incident, submit an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month, to the relevant CSIRT/authority, and inform affected recipients where appropriate.

  EvidenceArtifact
• UnverifiedRegister as an entity where required

  Where in scope, register with the competent authority / be listed in the entity registry, keeping contact and service information current.

  No code evidence yet
• PartialAccess control, MFA, and asset management

  Enforce access control on a least-privilege basis, multi-factor authentication (or continuous/secured authentication), asset management, and secured communications for staff and administrative access.

  EvidenceCode
• UnverifiedBusiness continuity, backup, and crisis management

  Maintain business-continuity and disaster-recovery plans with tested backups and crisis-management procedures, so the service can be restored within defined objectives after a disruption.

  No code evidence yet
• PartialCryptography and encryption

  Use cryptography and encryption appropriately: personal and sensitive data encrypted in transit and at rest, with sound key management.

  No code evidence yet
• UnverifiedCyber hygiene and training

  Maintain basic cyber-hygiene practices and provide security-awareness training to staff with access to systems or customer data.

  No code evidence yet
• PartialIncident handling

  Operate an incident-handling capability: detection, triage, containment, eradication, recovery, and post-incident review, with defined roles and a runbook.

  EvidenceArtifact
• PartialAssess effectiveness of security measures

  Have policies and procedures to assess the effectiveness of the cybersecurity risk-management measures (testing, audits, metrics), so controls are verified, not assumed.

  EvidenceAssessed
• UnverifiedRisk analysis and information-security policy

  Maintain a documented information-security policy and a risk-analysis process that identifies, assesses, and treats risks to the systems that process customer data.

  No code evidence yet
• ImplementedSecure development and vulnerability handling

  Apply security in acquisition, development, and maintenance, including vulnerability handling and disclosure: track and remediate vulnerabilities in code and dependencies on a defined cadence.

  EvidenceArtifact
• PartialSupply-chain security

  Address security in the supply chain: assess the security posture of suppliers and service providers (model/embedding vendors, storage, connectors) and manage supplier-related risk.

  EvidenceCode

• UnverifiedApply the cloud/managed-service availability + integrity thresholds

  For a cloud computing service provider (and, mutatis mutandis, a managed service provider), treat an incident as significant when the service is completely unavailable for more than 30 minutes, when availability is limited for more than 5% of Union users (or 1 million, whichever is smaller) for more than one hour, or when the confidentiality, integrity, or authenticity of processed data is compromised by a suspectedly malicious action or with impact on the same user threshold.

  No code evidence yet
• UnverifiedAggregate recurring minor incidents into one significant incident

  Treat individually non-significant incidents collectively as one significant incident where they occur at least twice within six months, share the same apparent root cause, and collectively meet the financial-loss criterion of Article 3(1)(a).

  No code evidence yet
• UnverifiedClassify incidents against the significant-incident criteria (starts the Art 23 clock)

  Be able to determine whether an incident is 'significant' under the quantitative and qualitative criteria: direct financial loss exceeding EUR 500 000 or 5% of prior-year turnover (whichever is lower), exfiltration of trade secrets, death or considerable harm to a natural person's health, or a successful suspectedly-malicious unauthorised access capable of causing severe operational disruption. A significant incident triggers the NIS2 Art 23 reporting timeline.

  No code evidence yet
• UnverifiedCount user impact per the prescribed method

  When calculating the number of users impacted for the availability thresholds, count both the customers holding a contract that grants access to the systems or services, and the natural and legal persons associated with business customers who use those systems or services.

  No code evidence yet
• PartialApply the Annex technical and methodological measures, proportionately and documented

  Implement the technical and methodological cybersecurity risk-management requirements set out in the Regulation's Annex (the concrete specification of NIS2 Art 21(2) points (a)-(j)), sized to the entity's risk exposure, size, and incident likelihood. Where a requirement is qualified 'where appropriate', 'where applicable', or 'to the extent feasible' and is judged not to apply, document the reasoning comprehensibly.

  EvidenceArtifact

• PartialSafeguard user data against corruption and loss

  Protect user data against destruction or corruption, since destruction or corruption of data not used exclusively for professional purposes is a compensable head of damage under the PLD.

  EvidenceCode
• PartialPreserve records so relevant evidence can be disclosed

  Maintain the records needed to disclose relevant evidence in a liability claim (design and risk documentation, audit and operational logs, provenance), because a failure to disclose relevant evidence when ordered creates a presumption of defectiveness. Retain the ability to present such evidence understandably while protecting trade secrets.

  EvidenceArtifact
• UnverifiedTrack substantial modifications and manufacturer-role changes

  Track substantial modifications to the product, since a party that substantially modifies a product outside the manufacturer's control and then makes it available becomes a manufacturer for liability purposes; keep the initial and updated risk assessments that define whether a change is substantial.

  No code evidence yet
• PartialMeet safety-relevant cybersecurity requirements to avoid presumed defectiveness

  Assess and hold the safety a person is entitled to expect, including safety-relevant cybersecurity requirements, because a failure to comply with mandatory cybersecurity safety requirements creates a legal presumption that the product is defective, shifting the practical burden onto the manufacturer.

  EvidenceArtifact
• UnverifiedDetermine PLD scope for the software product and related services

  Establish which offerings are in scope: software and digital 'related services' supplied in the course of a commercial activity are products/components under the PLD from 8 December 2026, while free and open-source software developed or supplied outside a commercial activity is exempt. Record the determination and the manufacturer role.

  No code evidence yet
• PartialSupply the security updates needed to maintain safety

  Provide the software updates and upgrades necessary to maintain the product's safety for as long as it is within the manufacturer's control. A defect due to software, an update/upgrade, or the absence of a security update needed to maintain safety does not benefit from the liability exemption.

  EvidenceCode

• ImplementedMarket without creating confusion with a competitor's products or marks

  Marketing, including comparative advertising, that creates confusion with the products, trade marks, trade names or other distinguishing marks of a competitor is a misleading practice when it affects the consumer's decision (art_6 paragraph 2 point a). Naming another product to identify it is lawful; borrowing its look, its mark or its name as one's own is not.

  EvidenceTest
• ImplementedPublish none of the per-se unfair practices

  Annex I lists the practices that are unfair in all circumstances, with no distortion test (art_5 paragraph 5). The ones a software marketing site can commit: claiming to be a signatory to a code of conduct, displaying a trust or quality mark without authorisation, claiming approval or endorsement by a public or private body one does not have, creating false urgency, paid editorial content not identified as such, and, from the 2024/825 amendment, a sustainability label not based on a certification scheme or established by a public authority, a generic environmental claim without recognised excellent environmental performance, and a claim of neutral, reduced or positive environmental impact based on offsetting.

  EvidenceArtifact
• PartialPublish no false or deceptive statement about the product, the price or the trader

  A practice is misleading if it contains false information, or if its overall presentation deceives or is likely to deceive the average consumer even when factually correct, about the product's main characteristics (including geographical or commercial origin, the results to be expected, and the results and material features of tests or checks), the extent of the trader's commitments, sponsorship or approval, the price or how it is calculated, or the trader's attributes, approvals, affiliations and awards, where it causes a transactional decision the consumer would not otherwise have taken (art_6 paragraph 1). Advertising a benefit that does not result from any feature of the product or business is misleading in the same way (art_6 paragraph 2 point e).

  EvidenceTest
• PartialState the material information at the invitation to purchase

  Omitting, hiding or presenting unclearly the material information the average consumer needs to decide is a misleading omission (art_7 paragraphs 1 and 2). At an invitation to purchase the material information includes the main characteristics of the product, the trader's identity and geographical address, the price inclusive of taxes or the manner in which it is calculated plus any additional charges, and the existence of a right of withdrawal where one applies (art_7 paragraph 4). Where consumer reviews are shown, whether and how the trader ensures they come from real customers is material too (art_7 paragraph 6).

  EvidenceCode
• ImplementedTreat every published marketing sentence as a B2C commercial practice

  A commercial practice is any act, omission, course of conduct, representation or commercial communication, including advertising and marketing, directly connected with the promotion, sale or supply of a product to consumers (art_2). The directive applies to every such practice before, during and after a transaction (art_3), and the general clause prohibits any practice contrary to professional diligence that distorts the average consumer's transactional decision (art_5). The public site reaches consumers in every locale it publishes, so every published sentence is inside the scope, not only the pricing page.

  EvidenceGate
• ImplementedHold the evidence for every factual marketing claim, ready on demand

  Courts and administrative authorities may require the trader to furnish evidence of the accuracy of factual claims made in a commercial practice, and may treat a claim as inaccurate when the evidence is not furnished or is insufficient (art_12). The burden sits with the trader from the moment the claim is published, so the evidence must exist before the sentence does, not be assembled after a complaint.

  EvidenceGate

• UnverifiedB3: report total energy consumption

  Report total energy consumption in MWh and, where the data allows, a breakdown of electricity as reflected in utility billings and of fuels into renewable and non-renewable. Voluntary for undertakings with 10 employees or fewer. Evidence typically held: electricity and heating invoices, fuel card statements, landlord service charge statements, energy supply contracts and guarantees of origin, meter readings. Value chain cap (Annex II): applies to undertakings with more than 10 employees; the datapoint is voluntary at 10 employees or fewer.

  No code evidence yet
• UnverifiedB3: report estimated gross scope 1 and scope 2 greenhouse gas emissions

  Report estimated absolute gross emissions in tonnes of CO2 equivalent following the GHG Protocol Corporate Standard (2004): scope 1 from owned or controlled sources and location-based scope 2 from purchased energy. Voluntary for undertakings with 10 employees or fewer. Evidence typically held: the energy documents above, fleet fuel receipts and mileage logs, refrigerant top-up and service records, grid emission factor tables. Value chain cap (Annex II): applies to undertakings with more than 10 employees; the datapoint is voluntary at 10 employees or fewer.

  No code evidence yet
• UnverifiedB4: report pollution of air, water and soil

  Report emissions of pollutants to air, water and soil from own operations that are reported to competent authorities under Union or national law, or voluntarily under an environmental management system. A link to an existing public report is enough. Evidence typically held: environmental permits, reports filed with the authority, environmental management system reports, inspection reports. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedB5: disclose sites in or near biodiversity-sensitive areas

  If the undertaking has sites in or near a biodiversity-sensitive area, disclose them and the name of the area. Evidence typically held: the site address list, planning and zoning permits, environmental impact assessments, authority maps of protected areas. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedB6: report water withdrawal and, where relevant, consumption

  Report total water withdrawal and, if production processes consume significant water, water consumption as withdrawal minus discharge, with the amount consumed at sites in water-stressed areas shown separately. Voluntary for undertakings with 10 employees or fewer. Evidence typically held: water utility invoices, meter readings, discharge permits. Value chain cap (Annex II): para 36 only, for undertakings with more than 10 employees.

  No code evidence yet
• UnverifiedB7: report circular economy practice and waste

  Say whether circular economy principles are applied and how, report total waste generated with the hazardous and non-hazardous split, the share diverted to recycling or reuse, and, in sectors with significant material flows, the annual mass flow of relevant materials. All of B7 is voluntary for undertakings with 10 employees or fewer. Evidence typically held: waste contractor invoices and consignment notes, recycling collection statements, hazardous waste manifests, material purchasing records, packaging specifications. Value chain cap (Annex II): para 38 first sentence and para 39(a) and (b), for undertakings with more than 10 employees.

  No code evidence yet
• UnverifiedB1: state the basis for preparation

  State whether the report follows Option A (Basic Module only) or Option B (Basic and Comprehensive Modules) with an explicit statement of compliance, name any disclosure omitted under the omission rules, say whether the report is individual or consolidated, and for a consolidated report list the subsidiaries with their registered addresses. Evidence typically held: the signed management report or board minute choosing the scope, group structure chart, company registry extracts for each subsidiary. Value chain cap (Annex II): applies to undertakings of every size. (points (a) and (c)).

  No code evidence yet
• UnverifiedB1: describe sustainability certifications and labels held

  If the undertaking holds a sustainability-related certification or label, briefly describe it, including the issuer, date and rating score where relevant. Evidence typically held: certificates and audit reports (for example an environmental management or occupational safety certification), the issuer's scoring letter, a registration number with the scheme. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier. Anything copied from these descriptions into marketing re-enters [[ucpd]] (see reports-and-claims-stay-truthful).

  No code evidence yet
• UnverifiedB1: report the undertaking's identifying and size data

  Report legal form, NACE sector code or codes, balance sheet total, turnover, number of employees as headcount or full-time equivalents, the country of primary operations and location of significant assets, and the geolocation of sites owned, leased or managed. Evidence typically held: company registry extract, annual report and financial statements, payroll or HR headcount export, lease agreements and property registers for site addresses. Value chain cap (Annex II): applies to undertakings of every size.

  No code evidence yet
• UnverifiedB2: state sustainability practices, policies and future initiatives

  If the undertaking has practices, policies or future initiatives for a more sustainable economy, say so, and state whether it has concrete practices (for example reducing water and electricity use or preventing pollution), policies on sustainability issues and whether they are public, forward-looking plans under way, and targets that monitor the policies. Evidence typically held: written policies (environmental, health and safety, HR, anti-corruption), board minutes approving plans, supplier code of conduct, project plans, partnership agreements. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedB11: report anti-corruption and anti-bribery convictions and fines

  Where there were convictions or fines in the reporting period, report their number and the total amount of fines for violating anti-corruption and anti-bribery law. Evidence typically held: court or authority decisions, counsel's letters, fine payment records. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedB10: report pay floor, collective bargaining and training

  State whether employees are paid at or above the applicable minimum wage, report the gender pay gap if Union or national law already requires it (footnote 8 names Directive (EU) 2023/970), the percentage of employees covered by collective bargaining agreements, and the average annual training hours per employee. Evidence typically held: payroll export, collective agreements, training records or learning platform exports, a statutory pay gap report where one exists. Value chain cap (Annex II): points (a), (c) and (d), for undertakings of every size.

  No code evidence yet
• UnverifiedB8: report workforce characteristics

  Report the number of employees as headcount or full-time equivalents by type of employment contract (temporary or permanent), by gender, and by country of the contract when operating in more than one country. Evidence typically held: payroll or HR system export, employment contracts, organisation chart. Value chain cap (Annex II): points (a) and (b), for undertakings of every size.

  No code evidence yet
• UnverifiedB9: report work-related accidents

  Report the number and rate of recordable work-related accidents and, subject to legal restrictions, the fatalities from recordable work-related accidents and ill health. Evidence typically held: the accident register, injury reports filed with the labour inspectorate, insurer claim records, timesheets for the hours worked that the rate needs. Value chain cap (Annex II): point (a), for undertakings of every size.

  No code evidence yet
• UnverifiedComprehensive module: consider scope 3 emissions alongside B3

  Where the undertaking's activities make scope 3 emissions relevant, it may quantify them, drawing on the fifteen categories of the GHG Protocol Corporate Value Chain Standard and including the significant categories by its own assessment. Scope 3 information is presented together with the B3 scope 1 and 2 figures. Evidence typically held: procurement ledgers, supplier invoices, business travel bookings, freight invoices. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedC3: report greenhouse gas reduction targets and any transition plan

  If targets exist, report absolute scope 1 and 2 targets (and scope 3 where set) with target year and value, base year and value, units, the share of emissions covered and the main actions. An undertaking in a high climate impact sector may describe a transition plan for climate change mitigation, and if it has none says whether and when it will adopt one. Para 53 is voluntary for undertakings with 10 employees or fewer. Evidence typically held: climate strategy documents, board-approved targets, investment plans, the NACE classification that decides the sector question. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedC4: report climate-related hazards and transition risks

  If climate-related hazards and transition events create risks, describe them, how exposure and sensitivity of assets, activities and the value chain were assessed, the time horizons and any adaptation actions. A rating of high, medium or low for the potential effects may be added. Para 56 is voluntary for undertakings with 10 employees or fewer. Evidence typically held: the risk register, insurer risk surveys, flood and hazard maps, business continuity plans. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedC1: describe the business model and strategy

  Describe significant groups of products and services, significant markets, main business relationships such as key suppliers, customers and distribution channels, and any elements of the strategy that relate to or affect sustainability issues. Points (a) to (d) are voluntary for undertakings with 10 employees or fewer. Evidence typically held: product catalogues, the annual report's business description, customer and supplier contracts and lists, strategy documents. Value chain cap (Annex II): points (a), (b) and (c), for undertakings with more than 10 employees.

  No code evidence yet
• UnverifiedC2: describe the B2 practices, policies and initiatives in more detail

  Briefly describe the practices, policies and future initiatives already reported under B2, mention where they cover suppliers or customers, describe any targets that monitor the policies, and optionally name the most senior person or body accountable. Evidence typically held: policy documents, the supplier code of conduct, board mandates. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedC8: report revenues from sensitive sectors

  If active in prohibited weapons, tobacco cultivation and production, the fossil fuel sector (with a coal, oil and gas split) or chemicals production (NACE Division 20.2), disclose the revenues derived from those activities. Evidence typically held: the revenue ledger by activity or NACE code, segment notes in the annual report. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedC9: report the gender diversity ratio of the governance body

  If the undertaking has a governance body, report its gender diversity ratio. Evidence typically held: the board or management register, articles of association, the annual report's management section. Value chain cap (Annex II): outside the cap, so a reporting customer may not demand it as of right from a protected supplier.

  No code evidence yet
• UnverifiedC5: report employee turnover and optional workforce detail

  Report the employee turnover rate for the period (voluntary for undertakings with 10 employees or fewer) and optionally the female-to-male ratio at management level, the number of self-employed people without personnel who work exclusively for the undertaking, and temporary workers supplied by employment agencies. Evidence typically held: HR joiner and leaver exports, payroll, contractor agreements, staffing agency invoices. Value chain cap (Annex II): para 58, for undertakings with more than 10 employees.

  No code evidence yet
• UnverifiedC6: report human rights policies and the complaints mechanism

  Answer yes or no on whether there is a code of conduct or human rights policy for the own workforce, which of child labour, forced labour, human trafficking, discrimination, accident prevention or other topics it covers, and whether a complaints-handling mechanism exists for the own workforce. Points (a) and (c) are voluntary for undertakings with 10 employees or fewer. Evidence typically held: code of conduct, employee handbook, human rights policy, whistleblowing or grievance procedure. Value chain cap (Annex II): points (a) and (c), for undertakings with more than 10 employees.

  No code evidence yet
• UnverifiedC7: report confirmed human rights incidents

  Answer yes or no on confirmed incidents in the own workforce involving child labour, forced labour, human trafficking, discrimination or other matters, optionally describe the actions taken, and report any confirmed incidents involving workers in the value chain, affected communities, consumers and end-users. Points (a) and (c) are voluntary for undertakings with 10 employees or fewer. Evidence typically held: grievance and incident logs, HR case records, supplier audit reports, complaint registers. Value chain cap (Annex II): para 62(a) and the first sentence of 62(c), for undertakings with more than 10 employees.

  No code evidence yet
• ImplementedKeep what a sustainability report says apart from what marketing may claim

  A report under the standard primarily informs business counterparties, and the undertaking decides whether to make it public (Annex I para 20). Any sentence, figure or badge from the report that reaches a consumer-facing page becomes a business-to-consumer commercial practice under [[ucpd]], where the Directive (EU) 2024/825 amendments apply from 27 September 2026: a generic environmental claim without recognised excellent environmental performance, a sustainability label not based on a certification scheme or established by a public authority, and a claim of neutral, reduced or positive impact based on offsetting are unfair in all circumstances, and the trader must hold evidence for every factual claim (UCPD Art 12). Reporting a metric under B3 is disclosure; it does not give a trader recognised excellent environmental performance, so a marketing line that turns a reported figure into a general green or climate-friendly description is the exposure.

  EvidenceGate
• UnverifiedPrepare a report that is relevant, comparable and consistent with the financial statements

  The report provides relevant, faithful, comparable, understandable and verifiable information. From the second year it carries prior-year comparatives except for metrics disclosed for the first time. Items under the if-applicable principle are reported only where the stated circumstances apply, and omission is taken to mean not applicable. A parent may consolidate subsidiaries, which then do not report separately. The report is annual when counterparties need annual updates and aligns with the financial reporting period. It may point to disclosures published elsewhere in the same document set. Information may be omitted only for a serious commercial prejudice, a trade secret, classified information or a legal protection, each omission is declared under B1 and reassessed at each reporting date, and the report is coherent with the financial statements.

  No code evidence yet
• UnverifiedUse the standard only as a voluntary, modular framework

  An undertaking that is not subject to mandatory reporting under Articles 19a and 29a of Directive 2013/34/EU may report sustainability information under the standard in Annex I (art_2). The standard is intended for undertakings with an average of up to 1 000 employees. It has two modules and the Basic Module is a prerequisite for the Comprehensive Module; a chosen module is complied with in its entirety, apart from items that apply only if the stated circumstances are met. Assurance is not required (recital 5). EFRAG practical guidance may be used but is not part of the standard (art_2).

  No code evidence yet
• UnverifiedTrack the dates the regulation and its cap apply from

  The delegated regulation was published in the Official Journal on 21 September 2026 and entered into force on the third day after publication, 24 September 2026, so the voluntary standard is usable from that date. The value chain cap in Article 3 applies from financial years beginning on or after 1 January 2027 (art_4, recitals 6 and 7).

  No code evidence yet
• UnverifiedTreat Recommendation (EU) 2025/1710 as no longer in effect

  From the date of entry into force, Recommendation (EU) 2025/1710 on the voluntary standard for small and medium-sized undertakings produces no legal effects (recital 5). Questionnaires and procurement templates that cite the recommendation need to be read against Annex I of this regulation. Financial institutions are still encouraged to limit sustainability data requests to undertakings with 1 000 employees or fewer to the information in Annex I.

  No code evidence yet
• UnverifiedAnswer reporting customers within the value chain cap

  A reporting undertaking under Articles 19a and 29a of Directive 2013/34/EU may require from a supplier with an average of up to 1 000 employees no more than the datapoints in Annex II (art_1, art_3). Annex II lists the capped datapoints in two bands, for undertakings with 10 employees or fewer and for undertakings with more. Only essential datapoints are in the cap (recital 4). The cap governs information gathering for the customer's own sustainability reporting and leaves untouched requests needed for other Union or national legal obligations. Directive (EU) 2026/470 inserted the matching rights into Article 19a(3) of Directive 2013/34/EU: a protected undertaking may decline a request that exceeds the voluntary standard, the reporting undertaking may rely on a self-declaration of protected status, and a contract term that demands more is not binding on that point. Member States transpose Articles 1 to 3 of that Directive by 19 March 2027.

  No code evidence yet

• PartialSay which checkpoints carry a stamp, and claim nothing more

  The published verification document distinguishes anchored from unanchored checkpoints with a watermark that is null until a stamp exists, and describes an anchor as a qualified time stamp only once the provider is qualified; a stamp from a non-qualified provider is described as what it is, admissible under Art. 41(1) without the Art. 41(2) presumption.

  EvidenceTest
• PartialAnchor audit-chain checkpoints with a qualified electronic time stamp

  Bind each audit-chain checkpoint's canonical digest to a date and time through a qualified electronic time stamp (an electronic time stamp that meets Art. 42, issued by a qualified trust service provider), so the checkpoint enjoys the presumption of the accuracy of its time and of the integrity of the bound data (Art. 41(2)). A non-qualified stamp keeps admissibility (Art. 41(1)) but not the presumption, and nothing we publish may claim the presumption before the provider is qualified.

  EvidenceTest
• PartialVerify the stamp's binding to the data before relying on it

  Before storing or publishing a time stamp, verify that it binds the date and time to exactly the data it was requested over (the checkpoint digest and the request nonce), that the binding cannot be altered undetectably (the CMS signature over the token's signed content verifies with a signer certificate issued for time stamping), and that the token carries the time source's statement (genTime). Keep the token with the checkpoint so any reader can repeat the verification from the published document alone.

  EvidenceTest
• PlannedTake stamps only from a provider on an EU trusted list

  Choose a time-stamping provider whose qualified status for that service is granted by a Member State supervisory body and published on that state's trusted list (Art. 20-22); a stamp from such a provider is qualified and is recognised as qualified in every other Member State (Art. 24a(6)). Pin the provider's trust anchor from the trusted list, validate each token's certificate chain to it, and re-check the listing on the cadence at which the status can change (a conformity audit at least every 24 months, Art. 20(1)).

  No code evidence yet

• PartialConfidentiality of communications and usage

  Do not listen to, intercept, store, or otherwise monitor users' communications and their content beyond what is necessary to provide the requested service, without their consent.

  EvidenceCode
• ImplementedConsent before non-essential storage or access on the user's device

  Store information on, or read information from, a user's terminal equipment (cookies, localStorage, similar) only with prior informed consent, except where strictly necessary to provide the service. Consent must be an opt-in: non-essential categories default to off, and refusing must be as easy as accepting.

  EvidenceArtifact
• UnverifiedErase or anonymise traffic data when no longer needed

  Erase or make anonymous traffic data (connection logs, technical metadata) when it is no longer needed to transmit the communication or to bill for the service, unless a lawful retention basis applies.

  No code evidence yet
• ImplementedOpt-in for unsolicited electronic marketing

  Send unsolicited electronic marketing (email, similar) only to recipients who have given prior consent, with a clear opt-out in every message; the existing-customer soft opt-in for similar products is the only narrow exception.

  EvidenceArtifact
• UnverifiedApply GDPR where ePrivacy is silent

  Treat ePrivacy as lex specialis for communications confidentiality and terminal-equipment access; where it is silent (lawful basis, data-subject rights, breach handling), the GDPR governs. National transpositions may add specifics.

  No code evidence yet
• PartialSecurity of the service

  Take appropriate technical and organisational measures to safeguard the security of the service, and inform users of any particular risk of a security breach.

  EvidenceArtifact

Grounded via the public wcag-2-2 crosswalk anchor; the proprietary standard's text is never stored.

• PartialMeet the clause 9 web requirements of the version we engineer to

  Conform to the standard's web clauses (which mirror WCAG success criteria at AA level) for the service's web surfaces. v4.1.1 aligns clause 9 to WCAG 2.2 AA, the bar the internal suite already enforces. Conformity yields a presumption of conformity only under an act whose Official Journal citation names this version: today none under the EAA, and v3.2.1 under the Web Accessibility Directive.

  EvidenceGate

• ImplementedRate limiting and anti-automation controls

  Implement rate limiting and anti-automation controls to protect against automated abuse, resource exhaustion, and brute-force attacks.

  EvidenceTest
• UnverifiedProtect authentication against brute force and offer MFA

  Implement controls against credential stuffing and password brute force, and support a multi-factor (or equivalent multi-mechanism) authentication option for user accounts.

  No code evidence yet
• ImplementedEnforce function- and data-level authorization at a trusted layer

  Restrict function-level and data-specific access to consumers with explicit permissions, enforce authorization at a trusted service layer (not client-controllable), and base object access on the originating subject's permissions.

  EvidenceAssessed
• PartialClassify sensitive data and bound its retention

  Identify and classify sensitive data into protection levels with documented protection requirements, return only the minimum sensitive data needed, and subject sensitive data to retention classification so outdated data is removed.

  EvidenceCode
• ImplementedValidate uploaded files by type, extension, and size

  Validate uploaded files against permitted types/extensions and maximum size, check compressed files against a maximum uncompressed size (zip-bomb defense), and enforce per-user storage/file-count quotas.

  EvidenceTest
• PartialPrevent injection via parameterized queries and safe OS calls

  Use parameterized queries, ORMs, or otherwise safe database access to prevent SQL/NoSQL injection, and avoid unsafe OS command construction from untrusted input.

  No code evidence yet
• ImplementedProtect against Server-Side Request Forgery

  Protect against SSRF by validating untrusted URLs against an allowlist and blocking access to internal/private address ranges before the server makes outbound requests on behalf of user input.

  EvidenceTest
• PartialStructured security logging with correlation and no sensitive data

  Emit security-event logs with sufficient correlatable metadata (when/where/who/what) in a common processable format, and enforce that logging respects data protection levels so sensitive data and direct identifiers are not written to logs.

  EvidenceCode
• PartialContext-aware output encoding and sanitization of rendered content

  Apply context-appropriate output encoding for HTML/JS/URL contexts, and sanitize or disable user-supplied and model-generated scriptable content (Markdown, HTML, CSS) before rendering to prevent XSS.

  No code evidence yet
• PartialManage third-party components with remediation timeframes and an SBOM

  Maintain an inventory (SBOM) of third-party libraries and transitive dependencies, define risk-based remediation timeframes for vulnerable versions, and ensure the application contains only components within those timeframes and sourced from expected repositories.

  EvidenceGate

• PartialConstrain agent functionality, permissions, and autonomy

  Limit LLM-invoked tools/extensions to the minimum functionality needed, grant them least-privilege permissions on downstream systems, execute actions in the requesting user's security context, enforce complete mediation (authorization decided by downstream systems, not the LLM), and require human approval for high-impact actions.

  EvidenceCode
• PartialProtect training/RAG data integrity against poisoning

  Validate the integrity and provenance of data entering the knowledge base, detect hidden/adversarial content in ingested documents, restrict ingestion to trusted sources, and monitor for anomalous retrieval behaviour. Because user-supplied documents feed retrieval, treat the ingestion path as a poisoning surface.

  EvidenceGate
• ImplementedPrevent unauthorized retrieval of sensitive data from the knowledge base

  Enforce least-privilege access to retrieved data so the model cannot surface another tenant's or user's content, and restrict which data sources the model can reach. Access to embeddings and chunks must be scoped to the requesting tenant/user/ACL, not left to system-prompt instructions.

  EvidenceTest
• ImplementedPartition the vector store per tenant with permission-aware retrieval

  Implement fine-grained, permission-aware access control over the vector and embedding store so that in a multi-tenant environment one tenant's queries can never retrieve another tenant's embeddings. Enforce strict logical/access partitioning of datasets in the vector database.

  EvidenceTest
• PartialGround answers and surface source citations to counter hallucination

  Reduce misinformation and overreliance by grounding responses in retrieved, verified sources (RAG), attaching source citations, automatically validating key outputs, clearly labelling AI-generated content, and communicating reliability limits to users.

  EvidenceCode
• PartialMitigate direct and indirect prompt injection

  Constrain model behaviour with explicit system-prompt role/scope instructions, validate expected output formats with deterministic code, segregate and clearly denote untrusted external content (retrieved documents, tool results) so it cannot override instructions, enforce least-privilege on model-invoked functions, and require human approval for high-risk actions. Treat RAG-ingested content as an indirect-injection vector.

  EvidenceGate
• PartialHandle model output as untrusted before downstream use

  Adopt a zero-trust stance on model output: apply context-aware encoding for rendered content (HTML/Markdown escaping to prevent XSS), never pass model output unsanitized into shells, SQL, file paths, or email templates, use parameterized queries, and apply a strict Content Security Policy.

  EvidenceCode
• PartialKeep secrets and authorization out of the system prompt

  Never place credentials, connection strings, or authorization logic in the system prompt; enforce privilege separation and authorization checks in deterministic, auditable systems outside the LLM. Assume the system prompt is discoverable and design so its disclosure carries no security impact.

  EvidenceTest
• ImplementedBound inference consumption with rate limits and quotas

  Prevent denial-of-service and denial-of-wallet by applying per-source rate limiting and user quotas, validating input size, managing resource allocation, and monitoring for anomalous consumption. Guard the cost-per-use inference path against uncontrolled or automated abuse.

  Known limit: Three AI-specific threat classes are ranked low and are not addressed.

  EvidenceTest
• PartialSecure the model and dependency supply chain

  Vet third-party models and data providers (terms, privacy, training-data usage), maintain an SBOM, scan and patch vulnerable/outdated components, and gate dependency updates against compromised releases. Use models only from verifiable sources.

  EvidenceGate

• ImplementedPrevent broken access control

  Enforce access control server-side on a deny-by-default basis so users cannot act outside their intended permissions or access other tenants' data.

  EvidenceAssessed
• PartialHarden identification and authentication

  Protect authentication against automated attacks (credential stuffing, brute force), support strong/multi-factor authentication, and manage sessions securely.

  EvidenceCode
• PartialAvoid security misconfiguration

  Ship hardened, secure-by-default configuration, validate configuration, and avoid exposing unnecessary features, verbose errors, or default credentials.

  EvidenceCode
• PartialProtect data with sound cryptography

  Protect data in transit and at rest with current cryptography and sound key management, and avoid weak or misconfigured algorithms and protocols.

  No code evidence yet
• PartialPrevent injection

  Prevent SQL/NoSQL/command/template injection through parameterized queries, safe APIs, and context-aware output encoding of untrusted input.

  No code evidence yet
• PartialProtect software and data integrity

  Protect against integrity failures in the software supply chain and CI/CD pipeline, and avoid insecure deserialization of untrusted data.

  EvidenceCode
• PartialEnsure security logging and monitoring

  Log security-relevant events with sufficient detail for detection and response, monitor for anomalies, and avoid logging sensitive data.

  EvidenceArtifact
• PartialAddress insecure design

  Use secure design patterns and threat modeling so security is built into the architecture rather than bolted on, with defense-in-depth for high-risk flows.

  No code evidence yet
• ImplementedPrevent Server-Side Request Forgery

  Validate and restrict server-side requests built from user-supplied URLs, blocking access to internal and private address ranges.

  EvidenceTest
• ImplementedManage vulnerable and outdated components

  Maintain an inventory of components, monitor for known vulnerabilities, and patch or remove vulnerable and outdated dependencies on a defined cadence.

  EvidenceGate

• PartialEnforce an automated WCAG 2.2 AA scan over key surfaces in CI

  An automated accessibility suite runs the WCAG 2.2 AA ruleset against the app's key pages in the e2e pipeline and fails on violations, so regressions in markup-detectable criteria cannot land silently.

  EvidenceGate
• UnverifiedAudit key user journeys with assistive technology

  The success criteria automated scanners cannot judge (focus order sanity, meaningful sequence, error-recovery comprehension, actual screen-reader usability of chat and document flows) require a periodic manual audit with assistive technology.

  No code evidence yet

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• PartialDefined process for granting and revoking access

  Grant access through a defined process and revoke it through one, so that a departing user or a disconnected integration loses reach immediately rather than at the next review. Revocation must invalidate live sessions, not only future logins.

  EvidenceTest
• PartialAccount inventory, dormancy sweep and separated administrative accounts

  Know which accounts exist, including the service accounts nobody signs in as, disable the ones that have gone dormant, and keep administrative work on an account that cannot also do everyday work. The separation is only real if the everyday account cannot reach the administrative rights by asking for them.

  EvidenceGate
• PartialMulti-factor authentication on exposed and administrative access

  Require a second factor for externally exposed applications and for every administrative account, including administrative access held at a third-party provider. An operator account protected by a password alone is the shortest path to every tenant's data at once.

  EvidenceTest
• PartialRole-based access control that is defined, not implied

  Define roles and the rights attached to them explicitly, and derive a user's reach from their role rather than from accumulated individual grants. The definition has to be readable, because a role nobody can describe cannot be reviewed.

  No code evidence yet
• PartialApplication security testing on every change

  Test the application for security defects as it changes, both statically against the source and dynamically against the running system. Static analysis reaches the code that exists; only a dynamic test reaches what the deployed composition of that code actually answers, so one without the other covers half the duty.

  EvidenceGate
• ImplementedA secure development process with root-cause analysis and secure design defaults

  Run a documented development process that addresses security, apply secure design principles so that the safe path is the default one rather than the remembered one, and analyse the root cause of defects rather than only their instances.

  EvidenceArtifact
• ImplementedVetted components for security functions rather than hand-rolled ones

  Use standard, vetted implementations for security-relevant functions (cryptography, signing, authentication, request validation) instead of writing them per call site. The failure mode is not one bad implementation but several nearly-identical ones that drift, so the control is a single owning module per primitive, imported rather than reconstructed.

  EvidenceTest
• PlannedAudit logs collected somewhere other than the host that wrote them

  Collect audit records to a destination outside the system that produced them, so that losing or compromising that system does not also lose the record of what happened to it. This is the same duty whether the records are application audit records or network ones.

  No code evidence yet
• PartialStated logging requirements, a retention window, and review of what is logged

  State what each surface must log before asking whether it does, keep those records long enough to investigate an incident found late, and review them for anomalies on a stated cadence. Collection without review produces evidence for an incident nobody noticed.

  EvidenceGate
• PartialAudit logging of access to sensitive data

  Record who accessed sensitive data, when, and through which path, in a log detailed enough to reconstruct an incident afterwards. The log must not itself become a copy of the sensitive content it describes.

  EvidenceTest
• PartialData classification and documented data flows

  Classify data by sensitivity so that handling rules can attach to the class rather than to a reader's judgement, and document where each class flows, including out to third parties. A flow map that stops at our own boundary answers none of the questions a customer asks.

  EvidenceArtifact
• ImplementedA data-management process and an inventory of the sensitive data held

  Run a documented data-management process covering sensitivity, retention and disposal, and keep an inventory of the sensitive data actually held. An inventory maintained by hand rots, so the parts that can be derived from the running system should be derived from it.

  EvidenceArtifact
• ImplementedEnforced retention and disposal

  Retain data only for a defined window and dispose of it when the window closes, by a mechanism that runs on its own rather than on a support request. Disposal must reach derived copies, not only the record a user can see.

  Known limit: A cached copy of derived data can briefly outlive a deleted document.

  EvidenceTest
• PartialEncryption of data at rest

  Encrypt stored data on servers, databases and object storage. Storage-layer encryption is the floor; credentials that grant access to third-party systems on a user's behalf warrant application-layer encryption, so that access to the storage device alone does not yield usable secrets.

  EvidenceTest
• PartialEncryption of data in transit

  Encrypt sensitive data on every network hop, including the hops inside our own estate: browser to application, application to database, application to inference provider, and worker to object storage. A hop terminated at a reverse proxy and continued in clear text does not satisfy this.

  EvidenceTest
• ImplementedEncryption of data at rest on end-user devices

  Encrypt the data the product leaves on an end-user device. A desktop client that caches state locally puts a copy of that state outside every server-side control, so it needs its own protection at rest rather than inheriting the server's.

  EvidenceTest
• ImplementedAccess control lists scoped to the data owner

  Restrict access to stored data through access control lists enforced by the storage layer itself rather than by the calling application. For a multi-tenant SaaS the load-bearing form is row-level isolation: a query issued in one tenant's context cannot return another tenant's rows even when the application layer is wrong.

  EvidenceAssessed
• PlannedAutomated backups with recovery actually tested

  Back up automatically, protect the recovery data from the same compromise that would take the primary, and test a restore on a fixed cadence. An untested backup is an assumption; the test is what converts it into a control, and the measured restore time is the number that matters.

  No code evidence yet
• PlannedAuthenticated sending domain for outbound mail

  Publish sender-authentication records so that mail claiming to come from our domain can be verified and mail that cannot be verified is handled as the policy says. A publish-and-forget posture is not enough: the records have to agree with the services that actually send, or the policy rejects our own mail.

  No code evidence yet
• ImplementedRoutine exercises of the incident-response process

  Exercise the incident-response process on a stated cadence, against scenarios written down in advance, and treat what the exercise gets wrong as the output. An exercise whose findings are not tracked to a close is a story about a rehearsal.

  EvidenceArtifact
• PartialAn incident-response process with a named owner, a reporting route and a review step

  Name who runs an incident, keep the contact list they will need, publish how anyone reports one, write the process down end to end, exercise it before it is needed, and review each incident afterwards. Every part of this is documentation, which is why the only real question is whether it exists and has been tried.

  EvidenceArtifact
• ImplementedMalware defences over the content the product ingests

  Scan the content that enters the system for malicious files and keep the detection signatures current automatically. For a platform with no managed endpoint fleet, the surface this safeguard actually protects is the ingestion path: files arriving from a user's upload or a connected source.

  EvidenceTest
• PlannedA penetration-testing programme, including as an authenticated user

  Test the system the way an attacker would, on a stated cadence and with a defined scope, including from the position of a legitimate authenticated user. A multi-tenant platform's most valuable finding is reachable only from inside a session, so an unauthenticated test alone measures the wrong boundary.

  No code evidence yet
• PartialSeparated production, staging and development environments

  Keep production separate from the environments used to build and test, so that development data cannot reach production and a production credential cannot be picked up by a test run. Separation asserted in configuration is only as strong as what refuses when the assertion is missing.

  EvidenceTest
• PartialStandard hardening templates for the application infrastructure

  Configure servers, containers and the database from a documented hardening baseline rather than from defaults, remove the services and default accounts that baseline does not need, restrict what each host will accept a connection from, and re-apply the baseline when a host is rebuilt. The baseline is only a control if compliance with it can be measured, so it has to be machine-checkable.

  No code evidence yet
• ImplementedAssessment of service providers against their classification

  Assess each service provider on a cadence that follows from its risk classification, record what was checked and where it was read, and let an assessment expire rather than stand indefinitely. The security requirements in the arrangement are what an assessment mostly checks, so the record has to name them one by one rather than reach a verdict as a whole.

  EvidenceArtifact
• ImplementedDecommissioning a service provider

  Ending a provider relationship has to leave evidence: what happened to the data we sent them, and that the credentials reaching them were revoked. Editing a row to say a provider is gone records the intention, not the act, and the credential is the part that outlives the intention.

  EvidenceGate
• ImplementedRisk classification of service providers

  Classify every service provider by the risk it carries, keep the classification current, and let it drive how much diligence the rest of the provider controls apply. A tier has to reflect what the provider can reach, whose law can compel it, who it engages in turn, and what our arrangement with it actually covers. The classification has to be derived from recorded facts rather than authored, because a tier table typed by hand describes the day it was written and nothing makes it move when a provider does.

  EvidenceArtifact
• PartialSecurity requirements in service provider arrangements

  Bind service providers to security requirements in the arrangement itself, and monitor them against it afterwards. For a processor chain that touches customer data the requirements have to cover location of processing, sub-processing and breach notification, because those are the terms a customer will be audited on.

  EvidenceGate
• PartialInventory of third-party components and service providers

  Maintain a current inventory of the third-party software components the product ships, keep them on vendor-supported versions, and update them from trusted sources. The inventory must be generated from what actually ships, not from a list someone remembers to update, and an unsupported component has to be visible as such rather than merely old.

  EvidenceGate
• ImplementedVulnerability management process for the software we ship

  Run a documented vulnerability-management process, scan the software the product is built from automatically rather than on request, and remediate on a published timeline tied to severity. A scan whose findings have no remediation deadline is a report, not a control.

  EvidenceArtifact
• PartialPatching and vulnerability scanning of the hosts we will run

  Patch operating systems and applications on a schedule, and scan both from inside the estate with credentials and from outside it as an attacker would. Each of these reaches defects the others cannot: an authenticated internal scan sees what is installed, an external scan sees what is exposed.

  No code evidence yet
• ImplementedA published intake channel for vulnerability reports, and a severity scale behind it

  Publish a way for anyone to report a vulnerability, including people with no relationship to us, and rate what arrives on a stated severity scale so that the response time follows from the rating rather than from who is asking.

  EvidenceArtifact

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• ImplementedAudit records cannot be silently altered once captured

  Captured audit and activity records are protected against modification or deletion through ordinary write paths once written; any legitimate correction runs through a narrowly-scoped, controlled path, never a direct mutation.

  EvidenceTest
• ImplementedEvery auditable event is captured with typed, enumerated metadata

  Auditable events are recorded with a fixed, enumerated event type and a typed metadata shape checked at the callsite, rather than reconstructed after the fact from free-text logs.

  EvidenceTest
• ImplementedRecords stay retrievable to authorised reviewers throughout retention

  Authorised reviewers can locate, filter, and bulk-extract the record set throughout its retention period, gated by the same permission check the interactive viewer uses, and the export itself is audited.

  EvidenceTest
• ImplementedAudit logs are purged on a fixed, floored schedule

  Audit and activity logs are purged on a fixed schedule with a minimum-age floor rather than growing unbounded, on a path distinct from the usage-ledger disposition.

  EvidenceTest
• ImplementedEvery destructive action leaves a reason-coded, honest receipt

  Every destructive or erasure action on a record leaves an append-only receipt recording what was removed, how many rows, and why, and the receipt cannot over-claim what actually happened.

  EvidenceTest
• ImplementedRaw telemetry is frozen to a long-lived ledger before it is purged

  Raw usage telemetry is closed into a long-lived aggregate on a fixed schedule before disposal, and disposal never runs ahead of the freeze, so the accounting record survives the purge of the raw rows.

  EvidenceTest

Grounded via the public gdpr crosswalk anchor; the proprietary standard's text is never stored.

• ImplementedData accuracy: extracted content faithfully represents the source

  Text extracted from an ingested file represents the source correctly, with a quality signal that routes poor extractions to a stronger path rather than indexing damaged content as if it were clean.

  EvidenceTest
• ImplementedData completeness: every ingested document is searchable or visibly failed

  The retrievable corpus reflects what was ingested: a document either reaches a searchable state or a terminal failed state with a recorded reason, never a silent blank that is present in the file list yet absent from the index.

  EvidenceTest
• ImplementedData consistency: derived stores agree with the document they describe

  Chunks and embeddings derived from a document stay consistent with the document's own state, so a partially-written or half-deleted document cannot present as a whole, searchable one.

  EvidenceTest
• ImplementedData currentness: the index tracks the source over time

  As source documents change or are removed, the retrievable corpus reflects the current state: updates re-index and deletions propagate, so answers are not drawn from content that no longer exists at the source.

  Known limit: No measured target yet for how old the search index may be.

  EvidenceTest
• PartialData confidentiality: content is reachable only by authorised principals

  Stored corpus data is accessible only to the tenant and users authorised to see it, enforced at the data layer rather than by application-code discretion.

  EvidenceCode
• ImplementedData traceability: retrieved content is attributable to its source

  Every unit of retrievable data can be traced to the source document and location it came from, so a generated answer's citations point at real, locatable provenance.

  EvidenceTest

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• ImplementedAccess control on a need-to-use basis

  Establish and enforce access control so that access to information and systems is restricted to what each identity needs. In a multi-tenant SaaS the load-bearing control is data-plane tenant isolation: no tenant can read another tenant's rows.

  EvidenceAssessed
• UnverifiedICT readiness for business continuity

  Plan, implement, and test ICT continuity so the service can be restored within defined objectives after disruption, covering the primary database, object storage, and the vector index.

  No code evidence yet
• UnverifiedSecurity for the use of cloud services

  Define and manage security for the cloud services the platform consumes and offers, including data location, tenancy isolation, and provider responsibilities under the shared-responsibility model.

  No code evidence yet
• PartialProvision and revoke access rights over the lifecycle

  Manage the full lifecycle of identities and access rights: provisioning, periodic review, and timely revocation on role change or departure, for both application users and administrative access.

  EvidenceArtifact
• PartialInformation security incident management

  Plan for and manage security incidents: a defined process to detect, report, assess, respond to, and learn from incidents, with roles and a runbook.

  EvidenceArtifact
• ImplementedSecurity requirements inside supplier agreements

  Establish which security requirements a supplier agreement has to carry, and check each of them per supplier rather than judging the relationship as a whole. A verdict on a supplier is not a verdict on the terms, and it is the terms that are enforceable.

  EvidenceGate
• PartialSecurity in supplier and subprocessor relationships

  Assess and manage the security posture of suppliers and subprocessors (model/embedding vendors, storage, connectors), including how their compromise could reach our systems and data.

  EvidenceArtifact
• PartialEncrypt data in transit and at rest under managed key policy

  Use cryptography to protect confidentiality and integrity of data in transit and at rest, with sound key management appropriate to the data's sensitivity.

  No code evidence yet
• PartialPrevent leakage of information

  Apply measures to prevent information from leaking across trust boundaries: tenant data-flow isolation, network segmentation, and controls on egress paths that could exfiltrate customer content.

  EvidenceArtifact
• ImplementedRestrict access to information within applications

  Restrict access to information and application functions in line with the access-control policy, enforced at the data layer so authorization cannot be bypassed by a direct query path.

  EvidenceAssessed
• PartialSecurity-relevant event logging

  Produce, protect, and retain logs recording security-relevant events (access, changes, failures) with enough fidelity to investigate incidents, without logging PII or customer content.

  EvidenceCode
• PartialMonitoring for anomalous behaviour

  Monitor systems for anomalous activity and potential security events, with alerting thresholds that surface incidents fast enough to meet regulatory reporting clocks.

  EvidenceCode
• PartialSecure authentication including MFA

  Use secure authentication techniques proportionate to risk, including multi-factor authentication for privileged and administrative access, and safe secret/credential handling.

  EvidenceArtifact
• ImplementedSecure coding and application security testing

  Apply secure coding principles and test application security automatically: static analysis in the pipeline, secret detection, and dependency review, so insecure code is caught before release.

  EvidenceGate
• PartialSecure development lifecycle

  Establish and apply rules for secure development across the lifecycle: security in design, protected pipelines, separation of environments, and controls that keep secrets out of source.

  EvidenceCode
• ImplementedTrack and remediate technical vulnerabilities on a defined cadence

  Obtain information about technical vulnerabilities in the software and its dependencies, evaluate exposure, and remediate on a defined cadence, including third-party and transitive dependencies.

  EvidenceArtifact

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• UnverifiedObtain and allow withdrawal of consent

  Where processing relies on consent, obtain it in a recorded, unambiguous way and provide an equally easy mechanism to withdraw it, with withdrawal taking effect across all downstream processing.

  No code evidence yet
• ImplementedFulfil PII principals' access, correction, and erasure rights

  Provide mechanisms for PII principals to access, correct, and erase their PII, and to obtain a portable copy, within the required timeframes and across every store that holds the data.

  EvidenceTest
• UnverifiedRecord and control transfers of PII

  Record the categories of PII transferred to third parties and jurisdictions, and control transfers so PII does not leave the permitted region or reach unauthorized recipients.

  No code evidence yet
• PartialPrivacy by design and by default

  Build privacy into processing: collect and expose the minimum PII needed, isolate it per tenant/principal, and default to the most privacy-protective settings so no principal's PII is accessible beyond its purpose.

  EvidenceCode
• UnverifiedIdentify purposes and lawful basis for processing PII

  Determine, document, and limit the purposes for which PII is processed, and establish a lawful basis for each purpose. Processing outside the recorded purpose is a violation.

  No code evidence yet
• PartialLimit retention and dispose of PII

  Retain PII only as long as needed for the purpose, then delete or de-identify it, with disposal reaching every copy including derived data (embeddings, caches, backups).

  EvidenceCode
• UnverifiedProvide transparency information to PII principals

  Give PII principals clear information about the processing (identity, purposes, recipients, retention, rights) at or before collection, in accessible language.

  No code evidence yet
• PartialNotify controllers of privacy incidents

  Detect PII breaches and notify affected controllers without undue delay, with enough information for them to meet their own regulatory notification deadlines.

  EvidenceArtifact
• UnverifiedMaintain records of PII processing

  Keep records of the PII processing carried out on behalf of controllers (categories, purposes, recipients, transfers), sufficient to demonstrate accountability.

  No code evidence yet
• PlannedProcess customer PII only on documented instructions

  As a processor, process customer PII only on the controller's documented instructions, not for our own purposes, and support the controller's own PIMS obligations.

  No code evidence yet

Grounded via the public eu-ai-act crosswalk anchor; the proprietary standard's text is never stored.

• UnverifiedManage the AI system life cycle responsibly

  Apply defined, repeatable processes across the AI system life cycle (objectives, design, verification, deployment, monitoring, retirement) with quality controls at each stage.

  No code evidence yet
• PartialKeep records and logs of AI operation

  Record events over the AI system's operation sufficient to trace behaviour, investigate incidents, and demonstrate accountability, without logging PII or customer content.

  EvidenceCode
• PartialEnsure AI robustness, accuracy, and security

  Design AI systems to be accurate and robust against errors and adversarial manipulation (prompt injection, insecure output handling), with security controls proportionate to the risk.

  EvidenceCode
• PartialGovern data used by AI systems

  Manage the data used to build and operate AI systems for quality, relevance, provenance, and bias, and control how customer content flows into retrieval and generation.

  EvidenceCode
• PartialProvide information about AI systems to interested parties

  Give affected parties clear information that they are interacting with an AI system and about its capabilities, limitations, and intended use, sufficient to use it responsibly.

  EvidenceCode
• UnverifiedAssess impacts of AI systems on individuals and society

  Perform and document an assessment of the potential impacts of AI systems on individuals and groups (fairness, safety, fundamental rights) before and during deployment, and act on the findings.

  No code evidence yet
• PartialEstablish an AI management policy

  Define, approve, and maintain an AI policy setting the organisation's objectives and principles for responsible AI, aligned with its risk appetite and legal obligations.

  No code evidence yet
• PartialAssign AI roles, responsibilities, and accountability

  Define who is accountable for AI systems across their lifecycle, with clear roles for development, deployment, oversight, and incident handling.

  No code evidence yet
• UnverifiedEnsure human oversight of AI use

  Enable humans to oversee AI outputs, understand them, and intervene or override where consequential, rather than deferring automatically to the model.

  No code evidence yet
• UnverifiedManage third-party and model-provider relationships

  Manage risks from third parties in the AI value chain (model/embedding providers, GPAI upstreams): understand their capabilities and limitations, and obtain the documentation needed to meet our own obligations.

  No code evidence yet

• PartialPrevent tenant data and system-prompt leakage through generated output

  Retrieval is tenant-scoped at the database layer and the output stream is scanned for verbatim or codec-laundered system-prompt disclosure, so generation cannot become a data-exfiltration channel.

  EvidenceTest
• PartialGate abusive and jailbreak input before generation

  User input passes a moderation gate (EU-jurisdiction classifier) before any generation spend, rejecting jailbreak and abusive prompts at the chat boundary.

  EvidenceTest
• ImplementedVerify generated claims against the retrieved sources they cite

  Every citation in a generated answer is verified against the actual retrieved chunks before it reaches the user, so a confabulated reference cannot masquerade as a grounded one.

  EvidenceTest
• ImplementedMark AI-generated artifacts with machine-readable provenance

  Artifacts the assistant generates carry machine-readable AI-provenance marking in every shipped format, so downstream consumers can distinguish generated content from source material.

  EvidenceTest
• PartialDefend the generation pipeline against direct and indirect prompt injection

  Treat retrieved document content as untrusted data, not instructions: guard-wrap and escape untrusted blocks, neutralize marker forgery, and scan output for laundered exfiltration, so a document cannot hijack the assistant.

  EvidenceGate

• UnverifiedDocument the AI system's capabilities, knowledge limits, and failure modes

  State what the assistant can and cannot do, its knowledge cut-off and retrieval boundaries, and how outputs may be wrong, so operators and users interpret output correctly.

  No code evidence yet
• UnverifiedDocument the system's intended purpose, context, and requirements

  Record the assistant's intended purpose, business context, target users, and system requirements (including privacy and residency), so downstream risk mapping has a defined scope.

  No code evidence yet
• UnverifiedEvaluate fairness and bias in AI output

  Identify and evaluate fairness and bias risks appropriate to a document-grounded assistant (e.g. retrieval skew, answer bias from source imbalance).

  No code evidence yet
• PartialMaintain an inventory of AI systems and models in use

  Keep an inventory of the AI systems and third-party models the product depends on (chat, embedding, reranker, planner), including provider, region, and decommissioning state, so ownership and lifecycle are tracked.

  No code evidence yet
• UnverifiedEstablish a documented AI risk-management process with periodic review

  Define how the needed level of AI risk management is determined, executed, and periodically reviewed, so risk decisions are repeatable and auditable rather than ad hoc.

  No code evidence yet
• PartialEncode the trustworthy-AI characteristics into engineering policy

  Integrate the AI RMF trustworthiness characteristics (valid/reliable, safe, secure/resilient, accountable/transparent, explainable, privacy-enhanced, fair) into written engineering policy and design defaults, not just individual features.

  No code evidence yet
• PartialUnderstand and document the AI legal and regulatory requirements we are subject to

  Maintain a living, version-tracked record of the AI-relevant laws and standards the product must satisfy (EU AI Act, GDPR, DORA, NIST AI RMF/ISO 42001), so obligations are managed from an authoritative source rather than memory. Re-check when the source text changes.

  EvidenceCode
• PartialDefine and document human oversight of AI output

  Ensure a human can understand, review, and override the assistant's output, with oversight processes defined and assessed for the deployment context.

  EvidenceCode
• UnverifiedProvide feedback channels and communicate AI incidents

  Give end users a way to report problems with AI output, and communicate incidents and errors to affected actors, feeding fixes back into the system.

  No code evidence yet
• PartialMeasure AI performance with defined test sets and metrics

  Evaluate retrieval and generation quality against a maintained golden test set with documented metrics (recall, nDCG, MRR, hit-rate, schema validity), and re-run the evaluation to detect regressions.

  EvidenceCode
• PartialMonitor the AI system after deployment

  Operate post-deployment monitoring of the AI pipeline (latency, errors, provider health, tracing) so degradations and incidents are detected in production.

  EvidenceCode
• PartialExamine the AI system's privacy risk

  Assess and constrain the privacy risk of the AI pipeline: tenant isolation of retrieved context, no training on customer data, and EU data residency for model calls.

  EvidenceCode
• PartialAssign roles, accountability, and training for AI risk

  Define who is accountable for mapping, measuring, and managing AI risk, with executive ownership and role-appropriate training and lines of communication.

  No code evidence yet
• UnverifiedEvaluate AI system security and resilience

  Assess the assistant for AI-specific security and resilience risks (prompt injection, data exfiltration via retrieval, provider failure) and confirm controls hold.

  No code evidence yet
• PartialHandle failures and incidents in third-party AI dependencies

  Contain failures of third-party AI services so a provider outage or fault degrades gracefully instead of cascading, and recovers automatically.

  EvidenceArtifact
• PartialManage third-party and pre-trained model risk

  Have policies and controls for the risks of third-party AI (the hosted models we call): assess provider terms, data handling, and region, and monitor pre-trained models used in the pipeline.

  EvidenceCode
• PartialMake AI output explainable and traceable to its sources

  Ensure the assistant's answers are explainable via source attribution, so a user can trace each answer to the documents it was grounded in, and transparency/accountability risks are addressed.

  EvidenceCode

• PartialDetect: monitor for and analyze adverse events

  Monitor systems and services to find potentially adverse events, and analyze detected events to understand the associated activity and impact.

  EvidenceArtifact
• PartialGovern: understand obligations and manage cybersecurity + supply-chain risk

  Establish a cybersecurity risk-management strategy, understand the legal, regulatory, and contractual cybersecurity requirements that apply, and run a supply-chain risk-management program.

  EvidenceArtifact
• PartialIdentify: inventory assets and identify vulnerabilities

  Maintain inventories of the assets (including software components) that enable the organization to achieve its purpose, and identify, validate, and record vulnerabilities in those assets.

  EvidenceCode
• PartialProtect: identity, access control, and data security

  Manage identities and access permissions on a least-privilege basis, and protect the confidentiality, integrity, and availability of data at rest and in transit.

  EvidenceCode
• UnverifiedRecover: restore services after an incident

  Execute the recovery portion of the incident-response plan to restore assets and operations affected by an incident, and communicate recovery status to stakeholders.

  No code evidence yet
• PartialRespond: execute incident response and root-cause analysis

  Execute an incident-response plan when an incident is declared, coordinate with relevant third parties, and analyze incidents to establish what happened and the root cause.

  EvidenceArtifact

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• PartialApply engineering rigor in proportion to the worst consequence

  The depth of review, testing and evidence for an engineering activity follows the most significant adverse effect that activity can cause.

  EvidenceGate
• ImplementedBase every trustworthiness judgment on evidence

  A claim that an element is trustworthy rests on evidence that the criteria for trustworthiness are satisfied, and the evidence is checkable by someone other than its author.

  Known limit: Most evidence shows a control is written, not that it runs.

  EvidenceGate
• PartialDetect departures from design intent early enough to respond

  Monitor the behaviour of the system and the conditions it runs in against a model of normal, and capture enough data (including who or what did it) for the response to be proportionate. Detection that arrives after the loss has run its course does not satisfy the principle.

  EvidenceGate
• PartialMatch the force and speed of a response to the loss scenario

  Each loss scenario has a response whose immediacy and aggressiveness fit it: an automatic containment where minutes matter, a human decision where a wrong response would itself cause loss.

  EvidenceArtifact
• PartialGive each element the functions it needs and no more

  Each element can do what its job requires and nothing beyond it: unused protocols, services, ports and response headers are absent rather than disabled by convention.

  EvidenceTest
• ImplementedKeep resources available only while they are needed

  Data, credentials and capabilities exist only for the period they serve a purpose, then are removed, so a late compromise finds less to take.

  Known limit: Copies held by providers follow their terms, not our erasure ledger.

  EvidenceTest
• PartialDepend on as few trusted elements as practicable

  The set of elements whose correct behaviour the security of the whole depends on is kept as small as practicable, because each trusted element is an assumption.

  EvidenceGate
• PartialReveal as little about the system as practicable

  The design discloses no more than it must about its structure, versions and internals to someone probing it.

  EvidenceCode
• PartialKeep the design as simple as practicable

  Complexity is treated as a source of vulnerability: the design is no more elaborate than the requirement forces, because only simple things can be analysed with confidence.

  EvidenceGate
• UnverifiedRequire more than one party for the most consequential operations

  An operation whose misuse would be severe needs agreement from multiple authorised entities before it can run, so no single credential or person can perform it alone.

  No code evidence yet
• ImplementedSeparate domains with different protection needs

  Domains that need different levels of protection are separated physically or logically, so a compromise or error in one does not reach the other. For a multi-tenant service the load-bearing domain boundary is the tenant.

  Known limit: Tenants share one database cluster; separation is logical.

  EvidenceAssessed
• UnverifiedProtect an element only from less trustworthy elements

  A more trustworthy element does not need to be shielded from a less trustworthy one it depends on being trusted by, which keeps protections cheap and the trust order explicit.

  No code evidence yet
• PartialAllocate each element only the privileges its functions need

  Every account, role, service and process holds the privileges required for its specified functions and no more, and privileged use is separable from ordinary use.

  EvidenceGate
• PartialShare resources among as few elements as necessary

  A resource is shared only when sharing is needed and then among the fewest elements, because every sharing path is a path for leakage or interference.

  EvidenceTest
• PartialMediate every access to and operation on an element

  No access to data or operation on a system element bypasses a mediating check: the check is the only path, not one of several.

  EvidenceGate
• PartialRoute control functions through a reference monitor

  Control functions follow the reference monitor properties: always invoked, tamper-proof, and small enough to verify.

  EvidenceAssessed
• PartialScale protection to the worst failure of the element protected

  The strength and kind of protection around an element follow from the most damaging outcome of that element failing, so the element carrying customer content is protected harder than one carrying nothing sensitive.

  EvidenceTest
• PartialTrust an element only as far as its failure could cost

  An element is relied on to a degree that matches the harm its failure would cause: the more damaging the failure, the more evidence of trustworthiness the element needs before it is depended on.

  EvidenceArtifact
• PartialKeep protection unbroken for as long as it is needed

  A protection works at every moment it is required, including during startup, failover and maintenance, rather than only in the steady state.

  EvidenceTest
• PartialLayer independent mechanisms so one failure is not the loss

  Loss is prevented or limited by several coordinated mechanisms, each of which holds without relying on the others being intact.

  EvidenceTest
• PartialOperate well clear of the threshold where loss begins

  The system runs in a state space with room to spare between normal operation and the point at which loss occurs, so a surge or fault does not tip it over.

  EvidenceCode
• PartialShip the most protective configuration as the default

  A fresh or unconfigured instance starts in the safest state; relaxing protection is an explicit act that leaves a record.

  EvidenceTest
• PartialFail into a safe state

  When an element fails it neither causes unacceptable loss nor sets off another loss scenario: the failure mode is closed rather than open.

  EvidenceTest
• PlannedRecover without causing or leading to loss

  Restoring an element returns it to a protected state: a recovery does not reopen a closed path, restore stale credentials or lose integrity.

  No code evidence yet
• PlannedReplicate critical functions where loss would be severe

  A required capability is delivered by replicated functions or elements so a single failure does not remove it.

  No code evidence yet
• PartialKeep the abstractions that describe the system simple and exact

  Each component presents a small, precisely defined interface and hides its internal representation, so a reviewer can reason about it from the interface alone.

  EvidenceCode
• UnverifiedEstablish trustworthiness of each composition of elements

  Trustworthy parts do not add up to a trustworthy whole by themselves: each aggregate of interacting elements needs its own argument that the combination holds.

  No code evidence yet
• UnverifiedDeliver critical capability through varied structure where it pays

  Where a single flaw in one implementation would be severe, the capability is delivered through more than one structurally different implementation or varied behaviour.

  No code evidence yet
• UnverifiedMake an element trustworthy with minimal dependence on others

  An element achieves its own trustworthiness without leaning on the correct behaviour of many other elements.

  No code evidence yet
• UnverifiedManage complexity by decomposing and composing in a structured way

  The system is decomposed into elements with clear, limited interfaces and composed back through those interfaces, so each part can be reasoned about alone.

  No code evidence yet

• PartialDeploy and operate a secure development toolchain

  Follow recommended security practices to deploy, operate, and maintain the tools and toolchains used to develop and release software, so the pipeline itself is not a weak link.

  EvidenceCode
• ImplementedAcquire and verify well-secured third-party components

  Acquire and maintain well-secured software components (libraries, frameworks) from trusted sources, and verify that acquired third-party components comply with organizational security requirements.

  EvidenceGate
• ImplementedReview and analyze code against secure coding standards

  Determine and perform code review and/or automated code analysis against secure coding standards, recording and triaging discovered issues before release.

  EvidenceGate
• ImplementedTest executable code and triage findings

  Scope, design, and perform testing of executable code, recording and triaging discovered issues so they are addressed before release.

  EvidenceGate
• PartialShip secure-by-default settings

  Define a secure baseline by configuring each security-relevant setting so that the default configuration is secure, and so operators must consciously weaken rather than strengthen it.

  EvidenceCode
• PartialProtect stored code from unauthorized access and tampering

  Store all forms of code (source, executable, configuration-as-code) based on least privilege so only authorized parties can access it, and protect it from unauthorized tampering.

  EvidenceCode
• UnverifiedArchive releases with integrity and provenance data

  Securely archive the necessary files and supporting data (integrity verification information, provenance data) for each software release, and make integrity verification information available to acquirers where applicable.

  No code evidence yet
• ImplementedMaintain a vulnerability disclosure and remediation policy

  Have a policy addressing vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes to support it, including a researcher-facing contact.

  EvidenceArtifact
• ImplementedIdentify vulnerabilities in code and third-party components on an ongoing basis

  Continuously gather information on potential vulnerabilities in the software and its third-party components from public sources, and review/analyze/test code to identify or confirm previously undetected vulnerabilities.

  EvidenceArtifact

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• UnverifiedMaintain availability through backup and recovery

  Meet availability commitments through backup, recovery, and capacity management: tested restoration within defined objectives across all data stores.

  No code evidence yet
• PartialMonitor the system for anomalies and security events

  Monitor system components and operations to detect anomalies indicating a security event, with alerting fast enough to trigger the incident process within reporting deadlines.

  EvidenceCode
• PartialProtect system boundaries against external threats

  Protect the boundaries of the system: limit and inspect ingress/egress, and constrain outbound requests so the service cannot be turned into a pivot for exfiltration or internal network access.

  EvidenceCode
• PartialAuthorize, test, and control changes

  Manage changes to infrastructure and software through an authorized, tested, controlled process: version control, review, protected pipelines, and separation of duties, so unauthorized or untested changes cannot reach production.

  EvidenceArtifact
• PartialRespond to and recover from security incidents

  Evaluate security events, respond to identified incidents through a defined program, and recover affected systems and data to normal operation.

  EvidenceArtifact
• ImplementedLogical access is restricted to authorized identities

  Restrict logical access to information assets to authorized users on a least-privilege basis. For a multi-tenant SaaS the decisive control is enforced tenant isolation at the data layer, so no identity can reach another tenant's data.

  EvidenceAssessed
• PartialThe system, its boundary and its data flows are described from the code

  Maintain a current description of the system an auditor and a customer can read: which components process which data, where each processor sits, how data enters and leaves the boundary, and on what schedule. The description must be generated from or checked against the running code, because a hand-kept narrative drifts from the system within a release.

  EvidenceArtifact
• PartialEncrypt data in transmission

  Protect data in transit with encryption and integrity controls appropriate to its sensitivity, across client, service, and inter-service links.

  No code evidence yet
• PartialManage vendor and subprocessor risk

  Assess and monitor the risk that vendors and subprocessors introduce, including their access to data and the impact of their compromise, and impose commitments through agreements.

  EvidenceCode
• ImplementedDetect and remediate vulnerabilities and misconfiguration

  Identify vulnerabilities and configuration weaknesses in the software and its dependencies through automated scanning, and remediate them on a defined cadence.

  EvidenceArtifact
• PartialProtect confidential information over its lifecycle

  Identify confidential information and protect it through access restriction and encryption from creation to disposal, including secure erasure when retention ends.

  EvidenceArtifact

Grounded via the public nist-800-53 crosswalk anchor; the proprietary standard's text is never stored.

• PartialEncrypt customer data in transit and at rest

  All transport is TLS; at-rest encryption posture is asserted per storage provider and the S3 factory refuses to start without a declared at-rest posture, so an unencrypted backend cannot be wired in silently.

  EvidenceTest
• ImplementedIsolate tenants with database-enforced logical access control

  Every data-plane table enforces row-level security and document ACLs resolve to a deny-set before retrieval, so one tenant's corpus is unreachable from another tenant's session even under application bugs.

  EvidenceAssessed
• ImplementedOperate a reachable security-incident intake channel

  A published, machine-discoverable channel exists for reporting security incidents and vulnerabilities, with a stated policy and expiry-managed contact data.

  EvidenceArtifact
• ImplementedRecord security-relevant events in a tamper-protected audit trail

  User actions are recorded to an append-only audit log whose modification and deletion paths are blocked by database triggers, with the sole narrow exception of identity-nulling for erasure.

  EvidenceTest
• ImplementedDetect and remediate known vulnerabilities in dependencies

  Dependencies are audited for known vulnerabilities on a defined cadence and a minimum-release-age cooldown blocks freshly published (potentially compromised) versions from entering the tree.

  EvidenceArtifact
• ImplementedDisclose subservice providers with per-entity transfer basis and enforce the register in CI

  Maintain a typed register of every subservice provider that touches customer data (jurisdiction, parent company, transfer basis, third-country compulsion exposure) with reverse coverage against the code's actual credentials, published as the customer-facing disclosure.

  EvidenceGate

• ImplementedStore accounting records so they cannot be altered or lost within the retention period

  Accounting material must be kept securely for the whole retention period: safeguarded against destruction, loss, and after-the-fact modification. The ledger closes a month exactly once (no re-freeze with different numbers) and purge refuses to touch months still inside the retention window.

  EvidenceTest
• ImplementedRetain accounting records for at least five years after the financial year ends

  Keep accounting material, including the transaction records that support invoicing, for at least 5 years from the end of the financial year it concerns. The usage ledger is kept ~10 years to also satisfy the stricter German horizon (HGB s. 257) while the DE bookkeeping-nexus question is open.

  EvidenceTest