{ "schema_version": "1.0", "generated_at": "2026-05-23T16:36:32Z", "artifact_scope": "public_summary", "disclosure": "This public artifact exposes the buyer-safe per-control summary while intentionally excluding implementation, test, evidence, source-reference, and git-provenance paths. Full control mappings remain available through the signed compliance reviewer bundle on request.", "summary": { "total_controls": 177, "types": { "audit_finding": 21, "billing_integrity": 7, "claim_boundary": 49, "operational_principle": 5, "pdpl_article": 25, "routing_control": 9, "runtime_control": 61 }, "substantiation_types": { "code_test": 148, "dated_live_evidence": 16, "external_fact": 13 }, "controls_with_external_dependency": 14, "controls_with_tests": 156, "controls_with_coverage_gap": 5, "pdpl": { "control_entries": 25, "distinct_articles_referenced": 20, "controls_with_verbatim_descriptions": 23, "controls_with_tests": 22, "controls_with_external_dependency": 2, "controls_with_coverage_gap": 2 } }, "totals": { "total_controls": 177, "substantiation": { "code_test": { "count": 148, "percent": 83.6 }, "dated_live_evidence": { "count": 16, "percent": 9.0 }, "external_fact": { "count": 13, "percent": 7.3 }, "unspecified_pending": { "count": 0, "percent": 0.0 } }, "last_validated": "2026-05-23T16:36:32Z" }, "controls": [ { "id": "PDPL-ART-05-LAWFULNESS-CONSENT-WITHDRAWAL", "type": "pdpl_article", "substantiation_type": "code_test", "description": "Consent-based processing must stop when consent is withdrawn, and consent-scoped requests require an identifiable subject.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-11-consent", "label": "Implementing Regulation Art. 11 — Consent" }, { "anchor": "article-12-consent-withdrawal", "label": "Implementing Regulation Art. 12 — Consent withdrawal" } ] }, { "id": "PDPL-ART-01-11-SENSITIVE-DATA-DEFINITION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "Sensitive Data: Personal Data revealing racial or ethnic origin, or religious, intellectual or political belief, data relating to security criminal convictions and offenses, biometric or Genetic Data for the purpose of identifying the person, Health Data, and data that indicates that one or both of the individual’s parents are unknown.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-25-impact-assessment", "label": "Implementing Regulation Art. 25.1.a — DPIA triggered by Sensitive Data processing" } ] }, { "id": "PDPL-ART-18-DATA-DESTRUCTION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller shall, without undue delay, Destroy the Personal Data when no longer necessary for the purpose for which they were collected.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-8-right-to-request-destruction-of-personal-data", "label": "Implementing Regulation Art. 8 — Right to Request Destruction" } ] }, { "id": "PDPL-ART-29-CROSS-BORDER-TOKENIZATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "Cross-border processing must not send raw Saudi personal data externally; external routing is gated on true anonymization or rerouted locally.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "cross-border-article-2-general-provisions-for-the-transfer-of-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 2 — General Provisions" }, { "anchor": "cross-border-article-5-transfer-based-on-appropriate-safeguards-for-transferring-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 5 — Appropriate safeguards (BCR / SCC / Certifications / Codes of Conduct)" }, { "anchor": "cross-border-article-8-risk-assessment-of-transferring-or-disclosing-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 8 — Risk Assessment of Transfer" } ] }, { "id": "PDPL-ART-04-DATA-SUBJECT-RIGHTS-FRAMEWORK", "type": "pdpl_article", "substantiation_type": "code_test", "description": "Data Subject shall have the following rights pursuant to this Law and as set out in the Regulations.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-3-general-provisions-for-data-subject-rights", "label": "Implementing Regulation Art. 3 — General provisions for Data Subject Rights" }, { "anchor": "article-10-means-of-communication", "label": "Implementing Regulation Art. 10 — Means of Communication" } ] }, { "id": "PDPL-ART-07-CONSENT-NON-BUNDLING", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The consent referred to in paragraph (1) of Article (5) of this Law may not form a condition\nof providing a service or a benefit, unless such service or benefit is directly related to the\nProcessing of Personal Data for which the consent is given.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-11-consent", "label": "Implementing Regulation Art. 11 — Consent" } ] }, { "id": "PDPL-ART-09-SUPPORTING-RIGHTS-BOUNDARY", "type": "pdpl_article", "substantiation_type": "external_fact", "description": "1-The Controller may set time frames for exercising the right to access Personal Data\nstated in Paragraph (2) of Article (4) herein as stipulated in the Regulations. The Controller\nmay limit the exercise of this right in the following cases:\n\n a) If this is necessary to protect the Data Subject or other parties from any harm,\n according to the provisions set forth the Regulations.\n b) If the Controller is a Public Entity and the restriction is required for security\n purposes, required by another law, or required to fulfill judicial requirements.\n\n2-The Controller shall prevent the Data Subject from accessing Personal Data in any of the\nsituations stated in Paragraphs (1, 2, 3, 4, 5) and (6) of Article (16) herein.", "coverage_gap": true, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-3-general-provisions-for-data-subject-rights", "label": "Implementing Regulation Art. 3 — General provisions for Data Subject Rights" } ], "gap_severity": "acceptable" }, { "id": "PDPL-ART-10-DATA-MINIMIZATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller may only collect Personal Data directly from the Data Subject and may only\nprocess Personal Data for the purposes for which they have been collected. However, the\nController may collect Personal Data from a source other that the Data Subject and may\nprocess Personal Data for purposes other than the ones for which they have been collected\nin the following situations:\n\n1- The Data Subject gives their consent in accordance with the provisions of this Law.\n2- Personal Data is publicly available or was collected from a publicly available source.\n\n3- The Controller is a Public Entity, and the Collection or Processing of the Personal Data is\n required for public interest or security purposes, or to implement another law, or to fulfill\n judicial requirements.\n4- Complying with this may harm the Data Subject or affect their vital interests\n5- Personal Data Collection or Processing is necessary to protect public health, public\n safety, or to protect the life or health of specific individuals.\n6- Personal Data is not to be recorded or stored in a form that makes it possible to directly\n or indirectly identify the Data Subject.\n7- Personal Data Collection is necessary to achieve legitimate interests of the Controller,\n without prejudice to the rights and interests of the Data Subject, and provided that no\n Sensitive Data is to be processed.\nThe Regulations shall set out the provisions, controls and procedures related to what is\nstated in paragraphs (2) to (7) of this Article.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-19-data-minimisation", "label": "Implementing Regulation Art. 19 — Data Minimisation" }, { "anchor": "article-18-processing-data-for-a-purpose-other-than-the-one-for-which-it-was-collected", "label": "Implementing Regulation Art. 18 — Purpose limitation" }, { "anchor": "article-15-collecting-data-from-third-parties", "label": "Implementing Regulation Art. 15 — Collecting Data from Third Parties" } ] }, { "id": "PDPL-ART-12-TRANSPARENT-DISCLOSURE", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller shall use a privacy policy and make it available to Data Subjects for their\ninformation prior to collecting their Personal Data. The policy shall specify the purpose of\nCollection, Personal Data to be collected, the means used for Collection, Processing,\nstorage and Destruction, and information about the Data Subject rights and how to exercise\nsuch rights.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-4-right-to-be-informed", "label": "Implementing Regulation Art. 4 — Right to be informed" }, { "anchor": "article-20-disclosure-of-personal-data", "label": "Implementing Regulation Art. 20 — Disclosure of Personal Data" } ] }, { "id": "PDPL-ART-13-COLLECTION-NOTICE", "type": "pdpl_article", "substantiation_type": "code_test", "description": "When collecting Personal Data directly from the Data Subject, the Controller shall take\nappropriate measures to inform the Data Subject of the following upon Collection:\n\n1- The legal basis for collecting their Personal Data.\n\n2- The purpose of the Collection, and shall specify the Personal Data whose Collection is\n mandatory and the Personal Data whose Collection is optional. The Data Subject shall be\n informed that the Personal Data will not be subsequently processed in a manner\n inconsistent with the Collection purpose or in cases other than those stated in Article (10)\n of this Law.\n3- Unless the Collection is for security purposes, the identity of the person collecting the\n Personal Data and the address of its representative, if necessary.\n4- The entities to which the Personal Data will be disclosed, the capacity of such entities,\n and whether the Personal Data will be transferred, disclosed or processed outside the\n Kingdom.\n5- The potential consequences and risks that may result from not collecting the Personal\n Data.\n6- The rights of the Data Subject pursuant to Article (4) herein.\n7- Such other elements as set out in the Regulations based on the nature of the activity\n done by the Controller.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-4-right-to-be-informed", "label": "Implementing Regulation Art. 4 — Right to be informed (notice at collection)" } ] }, { "id": "PDPL-ART-04-1-RIGHT-TO-BE-INFORMED", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The right to be informed about the legal basis and the purpose of the Collection of their Personal Data.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-4-right-to-be-informed", "label": "Implementing Regulation Art. 4 — Right to be informed" } ] }, { "id": "PDPL-ART-04-2-RIGHT-TO-ACCESS", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The right to access their Personal Data held by the Controller, in accordance with the rules and procedures set out in the Regulations, and without prejudice to the provisions of Article (9) of this Law.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-5-right-of-access-to-personal-data", "label": "Implementing Regulation Art. 5 — Right of access to Personal Data" }, { "anchor": "article-6-right-to-request-access-to-personal-data", "label": "Implementing Regulation Art. 6 — Right to Request Access to Personal Data" } ] }, { "id": "PDPL-ART-04-3-RIGHT-TO-PORTABILITY", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The right to request obtaining their Personal Data held by the Controller in a readable and clear format, in accordance with the controls and procedures specified by the Regulations.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-6-right-to-request-access-to-personal-data", "label": "Implementing Regulation Art. 6 — Readable-format portability" } ] }, { "id": "PDPL-ART-04-4-RIGHT-TO-RECTIFICATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The right to request correcting, completing, or updating their Personal Data held by the Controller.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-7-right-to-request-correction-of-personal-data", "label": "Implementing Regulation Art. 7 — Right to Request Correction" }, { "anchor": "article-22-correction-of-personal-data", "label": "Implementing Regulation Art. 22 — Correction of Personal Data" } ] }, { "id": "PDPL-ART-04-5-RIGHT-TO-DESTRUCTION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The right to request a Destruction of their Personal Data held by the Controller when such Personal Data is no longer needed by Data Subject, without prejudice to the provisions of Article (18) of this Law.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-8-right-to-request-destruction-of-personal-data", "label": "Implementing Regulation Art. 8 — Right to Request Destruction" } ] }, { "id": "PDPL-ART-14-DATA-ACCURACY-VERIFICATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller may not process Personal Data without taking sufficient steps to verify the Personal Data accuracy, completeness, timeliness and relevance to the purpose for which it is collected in accordance with the provisions of the Law.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-22-correction-of-personal-data", "label": "Implementing Regulation Art. 22 — Correction of Personal Data" } ] }, { "id": "PDPL-ART-15-DISCLOSURE-PERMITTED-SITUATIONS", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller may not Disclose Personal Data except in the following situations:", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-20-disclosure-of-personal-data", "label": "Implementing Regulation Art. 20 — Disclosure of Personal Data" } ] }, { "id": "PDPL-ART-16-DISCLOSURE-PROHIBITIONS", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller shall not disclose Personal Data in the situations stated in Paragraphs (1, 2, 5) and (6) of Article (15) if the Disclosure:", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-20-disclosure-of-personal-data", "label": "Implementing Regulation Art. 20 — Disclosure limits" } ] }, { "id": "PDPL-ART-17-CORRECTION-PROPAGATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "If Personal Data is corrected, completed or updated, the Controller shall notify such amendment to all the other entities to which such Personal Data has been transferred and make the amendment available to such entities.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-7-right-to-request-correction-of-personal-data", "label": "Implementing Regulation Art. 7 — Right to Request Correction" }, { "anchor": "article-22-correction-of-personal-data", "label": "Implementing Regulation Art. 22 — Correction of Personal Data" } ], "remediation_status": "REMEDIATED" }, { "id": "PDPL-ART-19-TECHNICAL-AND-ORGANISATIONAL-MEASURES", "type": "pdpl_article", "substantiation_type": "external_fact", "description": "The Controller shall implement all the necessary organizational, administrative and technical\nmeasures to protect Personal Data, including during the Transfer of Personal Data, in\naccordance with the provisions and controls set out in the Regulations.", "coverage_gap": true, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-23-information-security", "label": "Implementing Regulation Art. 23 — Information Security" } ], "gap_severity": "acceptable" }, { "id": "PDPL-ART-20-BREACH-NOTIFICATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller shall notify the Competent Authority upon knowing of any breach, damage, or illegal access to personal data, in accordance with the Regulations.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-24-notification-of-personal-data-breach", "label": "Implementing Regulation Art. 24 — Notification of Personal Data Breach" } ] }, { "id": "PDPL-ART-22-DPIA-WORKFLOWS", "type": "pdpl_article", "substantiation_type": "code_test", "description": "The Controller shall conduct an impact assessment of Personal Data Processing in relation\nto any product or service, based on the nature of the activity carried out by the Controller,\nin accordance with the relevant provisions of the Regulations.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-25-impact-assessment", "label": "Implementing Regulation Art. 25 — Impact Assessment" } ] }, { "id": "PDPL-ART-28-LEGACY-CROSS-BORDER-CITATION", "type": "pdpl_article", "substantiation_type": "code_test", "description": "Legacy Article 28 cross-border-transfer wording has been removed from the NCA whitepaper. Article 28 is retained only as a drift guard for avoiding stale transfer citations; current cross-border-transfer posture is centered on Article 29 and operator/counsel review.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "cross-border-article-2-general-provisions-for-the-transfer-of-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 2 — General Provisions" } ] }, { "id": "PDPL-ART-30-COMPETENT-AUTHORITY-AND-DPO", "type": "pdpl_article", "substantiation_type": "external_fact", "description": "1- Without prejudice to the provisions of this Law and the powers of the Saudi Central\n Bank pursuant to applicable legal provisions, the Competent Authority shall be the\n entity in charge of overseeing the implementation of this Law and the Regulations.\n 2- The Regulations shall identify the situations where the Controller shall appoint one or\n more persons as personal data protection officer(s). and shall set the responsibilities\n of any such person in accordance with the provisions of this Law.\n 3- The Controller shall cooperate with the Competent Authority in performing its duties\n to supervise the implementation of the provisions of this Law and the Regulations,\n and shall take such steps as necessary in connection with the related matters\n referred to the Controller by the Competent Authority.\n 4- The Competent Authority, in order to carry out its duties related to supervising the\n implementation of the provisions of the Law and Regulations, may:\n A. Request the necessary documents or information from the Controller to ensure\n its compliance with the provisions of the Law and Regulations.\n B. Request the cooperation of any other party for the purposes of support in\n accomplishing supervisory duties and enforcement of the provisions of the Law\n and Regulations.\n C. Specify the appropriate tools and mechanisms for monitoring Controllers’\n compliance with the provisions of the Law and the Regulations, including\n maintaining a national register of Controllers for this purpose.\n D. Provide services related to Personal Data protection through the national register\n referred to in Subparagraph (c) of this Paragraph or through any other means\n deemed appropriate. The Competent Authority may collect a fee for the Personal\n Data protection services it may provide.\n\n 5- The Competent Authority may, at its discretion, delegate to other authorities the\n accomplishment of some of its duties that are related to supervision or enforcement\n of the provisions of the Law and Regulations.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 5, "implementing_regulation_refs": [ { "anchor": "article-32-data-protection-officer", "label": "Implementing Regulation Art. 32 — Data Protection Officer" } ] }, { "id": "PDPL-ART-31-RECORDS-OF-PROCESSING-ACTIVITIES", "type": "pdpl_article", "substantiation_type": "code_test", "description": "Without prejudice to Article (18) herein, the Controller shall maintain records, for such a\nperiod as required under the Regulations, of the Personal Data Processing activities, based\non the nature of the activity carried out by the Controller. Such records are to be available\nwhenever requested by the Competent Authority. The records shall contain the following\ninformation at a minimum:\n\n 1-Contact details of the Controller.\n 2-The purpose of the Personal Data Processing.\n 3-Description of the categories of Personal Data Subjects.\n 4-Any other entity to which Personal Data has been, or will be, disclosed.\n 5-Whether the Personal Data has been or will be transferred outside the Kingdom or\n disclosed to an entity outside the Kingdom.\n\n 6-The expected period for which Personal Data shall be retained.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-33-records-of-personal-data-processing-activities", "label": "Implementing Regulation Art. 33 — Records of Personal Data Processing Activities" } ] }, { "id": "AUDIT-001-RAW-PII-EXTERNAL-LEAK-PROTECTION", "type": "audit_finding", "substantiation_type": "code_test", "description": "Detection misses must not allow raw PII to reach external providers; zero-tokenization external requests are rerouted or blocked and audited.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [], "severity": "CRITICAL", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-003-BREACH-DEADLINE-ENFORCEMENT", "type": "audit_finding", "substantiation_type": "code_test", "description": "The 72-hour breach deadline is actively escalated and can block non-essential processing when enforcement is enabled.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-24-notification-of-personal-data-breach", "label": "Implementing Regulation Art. 24 — Notification of Personal Data Breach (72-hour clock)" } ], "severity": "CRITICAL", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-007-CONSENT-WITHDRAWAL-DATA-LAYER", "type": "audit_finding", "substantiation_type": "code_test", "description": "Consent withdrawal is enforced at the pipeline and rehydration layers so a consent-scoped request cannot bypass the data-layer guard.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [ { "anchor": "article-12-consent-withdrawal", "label": "Implementing Regulation Art. 12 — Consent withdrawal" } ], "severity": "HIGH", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-002-PREWRITE-COMPLIANCE-RECORDS", "type": "audit_finding", "substantiation_type": "code_test", "description": "External provider work must be preceded by a pending compliance record so crashes cannot hide cross-border processing from the audit trail.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "CRITICAL", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-004-ARABIC-NER-SAFETY-GATE", "type": "audit_finding", "substantiation_type": "code_test", "description": "Arabic requests must fail closed to amber or red when Arabic NER is unavailable, instead of silently flowing to the green external lane.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "HIGH", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-005-DETECTION-SAFETY-FLOORS", "type": "audit_finding", "substantiation_type": "code_test", "description": "Production detection settings are clamped or rejected when they would reduce the detector below the configured safety floor.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "HIGH", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-006-SUBJECT-RIGHTS-SLA-ENFORCEMENT", "type": "audit_finding", "substantiation_type": "code_test", "description": "Subject-rights requests must escalate as they approach or exceed SLA, rather than relying on a passive overdue counter.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-3-general-provisions-for-data-subject-rights", "label": "Implementing Regulation Art. 3 — 30-day rights-request SLA" } ], "severity": "HIGH", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-008-JSONL-ROTATION-CHAIN-BRIDGE", "type": "audit_finding", "substantiation_type": "code_test", "description": "JSONL rotation must preserve verifier continuity through explicit bridge records so append-only chain checks survive file rollover.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-009-RESTRICTED-HANDLING-SAFE-DEFAULTS", "type": "audit_finding", "substantiation_type": "code_test", "description": "Restricted-handling safeguards must default to production-safe settings and strict profiles must reject unsafe development overrides.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-010-UNIVERSAL-TRANSFER-RECORDS", "type": "audit_finding", "substantiation_type": "code_test", "description": "Every route decision writes a transfer-register record so in-Kingdom and external processing remain separately auditable.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-011-EVIDENCE-KEY-HARDENING", "type": "audit_finding", "substantiation_type": "code_test", "description": "Evidence-signing and compliance-integrity key material now has an explicit bootstrap and rotation path instead of relying on opaque operator-only handling.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-012-DATABASE-RETENTION-CONSTRAINTS", "type": "audit_finding", "substantiation_type": "code_test", "description": "Compliance retention is enforced below the application layer through retention-expiry columns and database delete-protection rules.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-013-ENV-PERMISSIONS-FAIL-CLOSED", "type": "audit_finding", "substantiation_type": "code_test", "description": "Strict deployment profiles now fail closed on missing auth configuration and expose unsafe .env permissions as a startup diagnostic instead of silently proceeding.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-014-ROTATION-SCRIPT-KEY-LEAK", "type": "audit_finding", "substantiation_type": "code_test", "description": "Master-key rotation tooling must not print new key material to stdout where CI/CD or shell history can capture it.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [], "severity": "LOW", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-015-LEGACY-KDF-V1-DEPRECATION", "type": "audit_finding", "substantiation_type": "code_test", "description": "Legacy KDF v1 vault rows are detected, warned, and upgradeable so the runtime can converge to HKDF-backed v2 rows.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "LOW", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-016-REGULATOR-IP-DENIAL-ALERTING", "type": "audit_finding", "substantiation_type": "code_test", "description": "Denied regulator access attempts must be written to the regulator access log so allowlist failures are audit-visible.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "LOW", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-017-QUASI-RISK-POLICY-SEPARATION", "type": "audit_finding", "substantiation_type": "code_test", "description": "Policy decisions on quasi-identifier suppression are made independently from the detector's advisory flag, so in-process detector tampering cannot silently open the green lane.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "severity": "LOW", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-018-DTE-ARBITER-SAFETY-FLOOR", "type": "audit_finding", "substantiation_type": "code_test", "description": "Optional DTE arbiter overrides are bounded by a detector-confidence safety floor and remain disabled by default unless explicitly enabled.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [], "severity": "LOW", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-019-PER-TENANT-SENSITIVE-THRESHOLD-OVERRIDE-MISSING", "type": "audit_finding", "substantiation_type": "code_test", "description": "Per PDPL Article 25 (privacy by design), tenants cannot tune sensitive-category thresholds. Every tenant uses the same _PRESCREEN_RE in sensitive.py.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [], "severity": "MEDIUM", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-020-OBFUSCATED-FRAGMENT-SILENT-DROP", "type": "audit_finding", "substantiation_type": "code_test", "description": "OBFUSCATED FragmentMatch is silently dropped when re-analysis returns nothing structural. Adversarial obfuscation is named as a weak slice in detector-mastery-plan.md but the silent-drop behavior is not documented anywhere.", "coverage_gap": false, "has_tests": true, "test_count": 6, "has_evidence_refs": true, "evidence_count": 5, "implementing_regulation_refs": [], "severity": "HIGH", "remediation_status": "REMEDIATED" }, { "id": "AUDIT-021-TREND-HISTORY-DISCLOSURE-FRAGMENTATION", "type": "audit_finding", "substantiation_type": "external_fact", "description": "The 'not_ready' overall status from a failing trend-history gate appears only in detector_release_scorecard_latest.md. A regulator reading detector-mastery-plan.md or detector-reviewer-pack-20260420.md alone would not see that the detector is currently failing the streak gate.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 4, "implementing_regulation_refs": [], "severity": "LOW", "remediation_status": "REMEDIATED" }, { "id": "CLAIM-VAULT-AES256GCM-PER-TENANT-DERIVATION", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The buyer-safe vault-encryption claim is backed by concrete AES-256-GCM encryption and per-tenant key-derivation tests.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-THREE-LANE-PII-ROUTING", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The three-lane routing claim is supported by policy-engine tests that prove green, amber, red, and fail-closed behavior.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-DETECTOR-PRESIDIO-SAUDI-RECOGNIZERS", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The detector claim is backed by tests that prove Presidio wiring plus Saudi-specific recognizer coverage for dictionary and expanded-name cases.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-OIDC-SSO-COOKIE-RECOVERY", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The OIDC sign-in claim is backed by callback tests that cover successful PKCE/state/nonce completion and recovery from the pending-login cookie.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-TENANT-ISOLATION-LAYERS", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The tenant-isolation claim is backed by pipeline and auth-layer tests that keep tenant identity scoped across vault, auth, and policy boundaries.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-REGULATED-TENANT-MAPPING-FAIL-CLOSED", "type": "claim_boundary", "substantiation_type": "code_test", "description": "Regulated deployment profiles reject browser sign-in when the deterministic tenant-mapping claim is missing or unusable.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-PROCESSING-RECORD-INTEGRITY-NEWER-HMAC", "type": "claim_boundary", "substantiation_type": "code_test", "description": "Processing-record continuity and newer-row keyed integrity are backed by verify-records coverage and the documented legacy-row caveat.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-REDIS-RATE-LIMIT-AUTH-BRUTEFORCE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The host-wide rate-limit claim is backed by API and red-team tests that prove throttling headers and brute-force rejection behavior.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-PROVIDER-CIRCUIT-BREAKERS", "type": "claim_boundary", "substantiation_type": "code_test", "description": "Provider-circuit-breaker behavior is backed by metrics and routing tests that prove degraded providers are isolated instead of silently retried forever.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-ENCRYPTED-OFFHOST-BACKUPS", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The backup claim is supported by the current operator runbook plus dated live evidence for encrypted-first backup, OSS replication, and restore-drill execution.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-GUARDED-DEPLOY-ROLLBACK", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The guarded-deploy claim is substantiated by dated rollout evidence and the production deploy script that enforces preflight, readiness, and rollback checks.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-SECURITY-TXT-DISCLOSURE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The published security.txt claim is backed by endpoint tests plus dated activation evidence.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-KMS-STARTUP-BOOTSTRAP-LIVE", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The startup-KMS claim is bounded to serving-image bootstrap on ACK and excludes tenant BYOK or HSM-backed custody from the live boundary.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "CLAIM-ACK-TWO-POD-TWO-NODE-PROOF", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The ACK runtime-capacity claim is bounded to the dated April 20 point-in-time proof and does not widen into blanket HA or failover language.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-ARABIC-NER-LIVE-ACK-PROOF", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The live Arabic-NER claim is supported by candidate-image preflight, health verification, and detector tests that prove the local-model path remains live.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-PLANNED-ACK-CONTINUITY-PROOF", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The continuity claim is bounded to the April 6 planned replacement and drain drill; it does not assert automatic failover or broader HA beyond that captured proof.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-DASHBOARD-LOGIN-SUBMIT-HARDENING", "type": "claim_boundary", "substantiation_type": "code_test", "description": "Claim text asserts dashboard login submit hardening, but the repo currently substantiates only controlled login-form behavior and button semantics, not a clearly-scoped hardening proof for the submit path itself.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CLAIM-SELF-ASSESSED-SECURITY-SCANS", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The scanning claim is limited to self-assessed automated scans and does not imply an independent review.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-COMPLIANCE-GOVERNANCE-REGISTERS-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The live governance-register claim is backed by breach, subject-rights, and transfer-risk tests that prove register creation, deadline logic, and chain verification.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-CONSENT-WITHDRAWAL-AND-PDF-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "Consent withdrawal, subject-export PDF, and consent metadata are backed by subject-rights and compliance tests that prove the withdrawal overlay survives in both processing records and exported evidence.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-12-consent-withdrawal", "label": "Implementing Regulation Art. 12 — Consent withdrawal" } ] }, { "id": "CLAIM-COMPLIANCE-API-SURFACES-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The compliance-surface claim is backed by admin and regulator-route tests that prove the core TRA and subject-rights operations are exposed through authenticated API surfaces.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-COMPLIANCE-METRICS-LIVE-IN-CODE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The metrics claim is intentionally bounded to live-in-code coverage: the repo ships the gauges and alert rules, while scrape freshness remains a deployment concern.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-COMPLIANCE-DASHBOARD-SURFACES-LIVE", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The repo carries local dashboard coverage for the compliance surfaces, but the current matrix validator only machine-checks Python tests and the dated live evidence does not itself prove every dashboard interaction path.", "coverage_gap": true, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "gap_severity": "medium" }, { "id": "CLAIM-SDAIA-DPIA-PHASES-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The SDAIA-shaped DPIA claim is backed by generator tests that prove the emitted DPIA structure includes the expected SDAIA portal phases.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-25-impact-assessment", "label": "Implementing Regulation Art. 25 — Impact Assessment" } ] }, { "id": "CLAIM-DASHBOARD-HTML-NO-CACHE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The dashboard-cache claim is backed by API tests that prove the HTML shell ships with no-store cache headers.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-OIDC-CALLBACK-FAILURE-REDIRECT", "type": "claim_boundary", "substantiation_type": "code_test", "description": "OIDC callback failures redirect back to the dashboard-safe surface instead of exposing raw JSON error responses.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-DETECTOR-SAUDI-NAME-CORPUS-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The expanded Saudi-name-corpus claim is backed by dictionary regression cases that prove the detector now recognizes broader name coverage than the earlier pilot baseline.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-DETECTOR-FP-SUPPRESSION-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The false-positive-suppression claim is backed by benchmark regression cases that prove documentation, support, and structured-noise bait cases no longer survive as live PII.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-DETECTOR-MIXED-SCRIPT-RECOVERY-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The mixed-script-recovery claim is backed by regression tests that prove Arabic boundary repair and mixed-script full-span recovery for Saudi names.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-DETECTOR-P95-CLOSURE-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The detector-p95 claim is backed by the current benchmark guard that enforces the 1K mixed workload latency budget.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-TENANT-BYOK-HSM-EXPANSION-PENDING", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "Tenant BYOK rollout and any HSM-backed custody expansion remain later work; they are not part of the current live-tenant boundary.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [] }, { "id": "CLAIM-INDEPENDENT-SECURITY-REVIEW-PENDING", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "Independent penetration testing and architecture review remain external work and have not yet been completed.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [] }, { "id": "CLAIM-SIGNED-TRANSFER-PACKAGE-PENDING", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "Provider inventory and signed SCC/DPA/TIA packaging remain pending external work and are not yet complete.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [] }, { "id": "CLAIM-IMMUTABLE-EVIDENCE-NOT-LIVE", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "Signed immutable-evidence tooling exists, but the caveat remains verbatim: the current live ACK baseline is not yet configured with a production immutable-evidence sink or a production WORM bucket.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-SOC2-ISO27001-NOT-OBTAINED", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "SOC 2, ISO 27001, and equivalent certification claims remain explicitly out of scope because no such certification has been obtained.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [] }, { "id": "CLAIM-PDPL-LEGAL-OPINION-NOT-OBTAINED", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "No external Saudi legal opinion has been obtained yet on the PDPL anonymization exemption boundary.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [] }, { "id": "CLAIM-PUBLIC-LOAD-BASELINE-BOUNDED", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "Load/scaling language remains bounded to the published dated single-pod synthetic baseline; broader shared-state or live-production benchmark claims remain out of scope.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "CLAIM-GOVERNANCE-WORKFLOWS-NOT-YET-EXERCISED", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "Real-world breach, TRA, and subject-rights exercises remain unwalked with production-like evidence even though the code paths are live.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [] }, { "id": "CLAIM-DPO-AND-AI-AGENT-REGISTRATION", "type": "claim_boundary", "substantiation_type": "external_fact", "description": "The founder/operator registration claim depends on external records rather than code or dated runtime evidence.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": false, "evidence_count": 0, "implementing_regulation_refs": [ { "anchor": "article-32-data-protection-officer", "label": "Implementing Regulation Art. 32 — Data Protection Officer" } ] }, { "id": "CLAIM-BROWSER-SESSION-PROOF-SCOPE", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The browser/session claim is intentionally about proof freshness limits, not about new functionality; the April 20 baseline still relies on the April 18 same-origin proof pack.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "CLAIM-SELF-CONTAINED-OPERATIONS", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The self-contained-operation claim is backed by the operational-AI import guard, which rejects new operational dependencies on external AI services.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "CLAIM-FORGEJO-CI-RUNTIME", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "CI-runtime wording is substantiated by the dated runtime audit that confirmed Forgejo Actions endpoints on git.datasitr.com and no GitHub mirror for this repo.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-CONTROL-MATRIX-CI-VALIDATED", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The traceability-matrix claim is backed by the validator test plus the dedicated CI workflow that renders and validates the matrix on every change.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "CLAIM-COMPLIANCE-JSONL-SINGLE-POD-BOUNDARY", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The compliance-register caveat is intentionally narrow: the append-only JSONL chain is tamper-evident, not tamper-proof, and the current live safety claim remains bounded to the single-pod backend.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-BILLING-INTEGRITY-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The billing-integrity claim is backed by billing verify-chain and retention-gate tests that prove hash-chain continuity, newer-record HMAC coverage, and retention enforcement.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-GREEN-LANE-LEGAL-MEMO-INTERNAL-ONLY", "type": "claim_boundary", "substantiation_type": "dated_live_evidence", "description": "The internal legal-memo claim is bounded by the caveat verbatim: This is internal DPO governance only, not external counsel sign-off, not a completed provider SCC/DPA/TIA package, and not regulator approval.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CLAIM-ROPA-DRILLDOWN-LOCAL-ONLY", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The claim is bounded by the caveat verbatim: This is local code/build truth only until the live regulator surface is separately refreshed and re-verified. The repo now substantiates the dedicated regulator-dashboard RoPA page, its URL-backed filters, and its drill-down interaction surface; the matrix's machine-checked test reference remains the Python-backed aggregate regulator endpoint because the local Vitest file sits outside the current Python validator scope.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [ { "anchor": "article-33-records-of-personal-data-processing-activities", "label": "Implementing Regulation Art. 33 — Records of Personal Data Processing Activities" } ] }, { "id": "CLAIM-DETECTOR-BENCHMARK-SNAPSHOT-PUBLISHED", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The benchmark-publication claim is bounded by the caveat verbatim: This is a dated in-repo benchmark snapshot on curated corpora, not an external audit and not a claim of production-wide coverage. The internal generated artifact preserves runtime and git provenance for reviewer use; the public mirror intentionally excludes dev-environment runtime details, branch names, working-tree status, and benchmark fixture paths.", "coverage_gap": false, "has_tests": true, "test_count": 7, "has_evidence_refs": true, "evidence_count": 4, "implementing_regulation_refs": [] }, { "id": "CLAIM-BYOK-CODE-READY-NOT-LIVE", "type": "claim_boundary", "substantiation_type": "code_test", "description": "The BYOK claim is bounded by the caveat verbatim: the code path exists in saudivault/key_custody.py and saudivault/provider_credentials.py; the live baseline still runs DataSitr-held master-key bootstrap only.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-GREEN-LANE-TOKENIZATION-GATE", "type": "routing_control", "substantiation_type": "code_test", "description": "Green-lane requests require true anonymization, explicit anonymization evidence, adequate detection coverage, tenant permission, and min-cohort evidence for quasi-identifiable records before any external provider call.", "coverage_gap": false, "has_tests": true, "test_count": 6, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-RED-LANE-SENSITIVE-DATA-BLOCK", "type": "routing_control", "substantiation_type": "code_test", "description": "Sensitive data and blocked-risk cases fail closed to local raw processing instead of leaving the Kingdom.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-25-impact-assessment", "label": "Implementing Regulation Art. 25.1.a — Sensitive Data DPIA trigger; red-lane block reflects DPIA-required posture" } ] }, { "id": "PRINCIPLE-SELF-CONTAINED-OPERATION", "type": "operational_principle", "substantiation_type": "code_test", "description": "Internal operations must not depend on external AI services outside the declared product-route allowlist, and the guard is CI-enforced.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "BILLING-HASH-CHAIN-INTEGRITY", "type": "billing_integrity", "substantiation_type": "code_test", "description": "Billing ledger events carry SHA-256 chain continuity and HMAC authentication for newer rows, with a verification surface for regulators and operators.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BILLING-RETENTION-GATE", "type": "billing_integrity", "substantiation_type": "code_test", "description": "Billing deletion is retention-gated for ten years by default, and any allowed deletion writes a tombstone plus a companion compliance record.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-VAULT-AES256GCM-ENCRYPTION", "type": "runtime_control", "substantiation_type": "code_test", "description": "The runtime token vault encrypts stored PII with AES-256-GCM and tenant-scoped derived keys.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-KMS-MASTER-KEY-BOOTSTRAP", "type": "runtime_control", "substantiation_type": "code_test", "description": "Startup master-key bootstrap on ACK resolves the runtime master key from Alibaba KMS rather than storing plaintext in the deployment manifest.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "ROUTE-AMBER-IN-KINGDOM-ENFORCEMENT", "type": "routing_control", "substantiation_type": "code_test", "description": "Amber-lane requests are restricted to the in-Kingdom provider pool and never select global providers.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-BLOCK-LANE-FAIL-CLOSED", "type": "routing_control", "substantiation_type": "code_test", "description": "Requests that do not satisfy an allowed policy path fail closed to the blocked-request path instead of silently downgrading to a different provider route.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-LOW-CONFIDENCE-REROUTE", "type": "routing_control", "substantiation_type": "code_test", "description": "Low-confidence or low-coverage detections stay out of the green lane and are rerouted to an in-Kingdom path.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-LANE-SCOPED-PROVIDER-FAILURE", "type": "routing_control", "substantiation_type": "code_test", "description": "Provider failures are lane-scoped: the pipeline falls back only within the current lane pool, and returns a fail-closed error when every provider in that lane is unusable.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-ARABIC-NER-DEGRADED-REROUTE", "type": "routing_control", "substantiation_type": "code_test", "description": "When Arabic NER is degraded, Arabic text is kept out of the green lane and is forced to amber or red depending on detected personal-data risk.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "ROUTE-QUASI-RISK-POLICY-GATE", "type": "routing_control", "substantiation_type": "code_test", "description": "High quasi-identifier risk is re-evaluated in the policy engine and keeps requests out of the green lane unless tenant policy explicitly allows suppression.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "DETECTOR-TECHNICAL-TEXT-FP-SUPPRESSION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Technical and code-like text uses structural suppression rules so configuration keys, YAML labels, and command snippets do not trigger false-positive person or phone detections.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "DETECTOR-MIXED-SCRIPT-SAUDI-NAME-RECOVERY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Detector late-recovery passes repair mixed-script Saudi person names that would otherwise be missed by the baseline recognizers.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "COMPLIANCE-PROCESSING-REGISTER-INTEGRITY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Processing records carry hash-chain continuity and HMAC authentication, with verifier support for legacy compatibility modes instead of silent integrity skips.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-33-records-of-personal-data-processing-activities", "label": "Implementing Regulation Art. 33 — Records of Personal Data Processing Activities" } ] }, { "id": "COMPLIANCE-TRANSFER-REGISTER-INTEGRITY", "type": "runtime_control", "substantiation_type": "code_test", "description": "The transfer register preserves append-only continuity and HMAC-backed authenticity for cross-border and in-Kingdom routing evidence.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "cross-border-article-2-general-provisions-for-the-transfer-of-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 2 — Cross-border transfer record-keeping" }, { "anchor": "cross-border-article-8-risk-assessment-of-transferring-or-disclosing-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 8 — Risk Assessment record" } ] }, { "id": "COMPLIANCE-BREACH-REGISTER-INTEGRITY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Breach-register entries remain append-only and verifiable, and their metrics surface overdue and approaching notification states without bypassing integrity checks.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-24-notification-of-personal-data-breach", "label": "Implementing Regulation Art. 24 — Personal Data Breach record" } ] }, { "id": "COMPLIANCE-SUBJECT-RIGHTS-REGISTER-INTEGRITY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Subject-rights requests remain append-only, verifiable, and regulator-readable without exposing raw request payloads.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "article-3-general-provisions-for-data-subject-rights", "label": "Implementing Regulation Art. 3 — Subject Rights request record" } ] }, { "id": "COMPLIANCE-TRA-REGISTER-INTEGRITY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Transfer Risk Assessment records remain append-only and verifiable through the same integrity surface as the other compliance ledgers.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [ { "anchor": "cross-border-article-8-risk-assessment-of-transferring-or-disclosing-personal-data-outside-the-kingdom", "label": "Cross-Border Transfer Regulation Art. 8 — Transfer Risk Assessment record" } ] }, { "id": "COMPLIANCE-CHAIN-VERIFICATION-ENDPOINTS", "type": "runtime_control", "substantiation_type": "code_test", "description": "Admin and regulator APIs expose explicit chain-verification endpoints for the processing, transfer, breach, subject-rights, TRA, and billing ledgers.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BILLING-VERIFY-CHAIN-ENDPOINT", "type": "billing_integrity", "substantiation_type": "code_test", "description": "The billing ledger exposes a super-admin verify-chain endpoint that reports continuity, HMAC coverage, legacy rows, and first/last timestamps.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "BILLING-DELETION-TOMBSTONE-COMPANION", "type": "billing_integrity", "substantiation_type": "code_test", "description": "Allowed billing deletion writes both a billing-ledger tombstone and a companion compliance record so post-retention cleanup remains auditable.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "BILLING-DECIMAL-PRECISION", "type": "billing_integrity", "substantiation_type": "code_test", "description": "Billing statements aggregate monetary values with Decimal arithmetic so micro-amount accumulation does not drift across large event volumes.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "BILLING-INTEGRITY-METRICS", "type": "billing_integrity", "substantiation_type": "code_test", "description": "The /metrics surface refreshes billing integrity gauges from the live ledger state before each scrape.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "BILLING-HMAC-ROTATION-COMPATIBILITY", "type": "billing_integrity", "substantiation_type": "code_test", "description": "Billing HMAC verification accepts both current and staged-previous billing keys so key rotation does not invalidate historical ledger authenticity.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "WEBHOOK-SIGNED-DELIVERY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Webhook deliveries are signed with an HMAC header when a tenant secret is configured.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "WEBHOOK-SSRF-ALLOWLIST-VALIDATION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Webhook URLs are validated against HTTPS, blocked-address, and optional hostname-allowlist rules at request time and again at delivery time.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "WEBHOOK-DURABLE-QUEUE-DELIVERY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Webhook deliveries are enqueued durably and replay through the background worker instead of blocking request completion on inline network I/O.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "RUNTIME-RATE-LIMIT-ENFORCEMENT", "type": "runtime_control", "substantiation_type": "code_test", "description": "Tenant API traffic is rate-limited with explicit Retry-After and X-RateLimit headers, and batch calls reserve quota atomically by item count.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-CORS-LOCKDOWN", "type": "runtime_control", "substantiation_type": "code_test", "description": "CORS is locked down by default and only relaxes to the development wildcard list when SV_DEV_MODE is explicitly enabled.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "SURFACED-RUNTIME-API-KEY-HMAC-DECOUPLING", "type": "runtime_control", "substantiation_type": "code_test", "description": "API-key hashing uses the dedicated SV_API_KEY_HMAC_SECRET when configured, so vault master-key rotation does not invalidate existing API keys; fallback to SV_MASTER_KEY remains explicit and load-bearing for backward compatibility.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "COMPLIANCE-INTEGRITY-METRICS", "type": "runtime_control", "substantiation_type": "code_test", "description": "The /metrics surface refreshes compliance-register existence, freshness, chain-intact, and processing-record HMAC-coverage gauges from live state before each scrape.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "PRINCIPLE-SELF-CONTAINED-ALLOWLIST-BOUNDARY", "type": "operational_principle", "substantiation_type": "code_test", "description": "The self-contained-operation guard keeps external AI confined to the declared product-route allowlist while quarantining dev-only AI tooling outside merge-eligible operational code.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-INBOX-MONITOR-LOCAL-GATEWAY", "type": "runtime_control", "substantiation_type": "code_test", "description": "The operations inbox monitor processes mail through a local detector/tokenizer gateway and a deterministic local draft client, with signed receipts recording only hashes, lengths, route metadata, and no raw outbound PII.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "RUNTIME-SAUDI-DATA-ENCLAVE-CUSTODY", "type": "runtime_control", "substantiation_type": "code_test", "description": "Licensed Saudi reference datasets are ingested into an encrypted enclave with signed policy-bound manifests, operator-controlled wrapped data keys, fail-loud plaintext source deletion, and verifier coverage for policy, manifest, encrypted file, and audit-chain integrity.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "RUNTIME-SAUDI-TRAINING-PREFLIGHT", "type": "runtime_control", "substantiation_type": "code_test", "description": "Before any licensed Saudi dataset is used for training, the preflight verifies enclave health, dataset training purpose, and explicit Saudi compute labels while rejecting Bahrain, UAE, Qatar, Kuwait, Oman, and ambiguous non-Saudi GCC region strings.", "coverage_gap": false, "has_tests": true, "test_count": 5, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "RUNTIME-HEALTH-NONBLOCKING-AUTHZ-SUMMARY", "type": "runtime_control", "substantiation_type": "code_test", "description": "The API health surface reports provider-authorization posture without bootstrapping shared-state PostgreSQL schema or waiting on the DB pool, keeping readiness checks deployment-safe while admin/provider routes remain authoritative.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "RUNTIME-DEPLOY-PACKAGE-OPERATIONAL-DATA-EXCLUSION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Deploy packaging excludes local operational artifacts such as inbox receipts, generated scratch state, regulatory drafts, evidence directories, data volumes, and heavyweight model checkpoints from source-control, Docker, and remote release staging paths.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "RUNTIME-API-HEAD-HEALTH-PROBES", "type": "runtime_control", "substantiation_type": "code_test", "description": "API health endpoints (/v1/health, /healthz, /readyz) accept HTTP HEAD in addition to GET so external uptime monitors that default to HEAD do not see false-down readings against the live ACK ingress. HEAD responses carry the same status, version, and no-cache headers as GET while omitting the body.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-INBOX-MONITOR-RECEIPT-RETENTION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Inbox monitor receipts are stored as date-partitioned signed JSONL files and are deleted after a configurable retention window (default 2555 days, suitable for the longest PDPL-aligned operational evidence window). A non-positive retention value disables sweeping. Malformed filenames are skipped without raising.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-DATA-ENCLAVE-AUDIT-CHAIN-ROTATION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Saudi data enclave audit-chain verification follows the JSONL rotation boundary. _verify_audit_chain reads any rotated events.jsonl.old before the active events.jsonl, validates the rotation_marker / rotation_bridge linkage, preserves sequence and previous-hash continuity across the boundary, and surfaces any rotation-related anomaly as an issue rather than silently passing on the post-rotation file alone.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "RUNTIME-DASHBOARD-LANE-BADGE-FAIL-CLOSED", "type": "runtime_control", "substantiation_type": "code_test", "description": "The customer-dashboard LaneBadge component renders localized lane labels (Green / Amber / Red) and falls closed to the Blocked label when an unknown lane string is passed. Surfaces the route-decision lane to operators with a deterministic, localized, fail-closed visual contract regardless of upstream payload shape.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "PROCESS-DETECTOR-AND-EXCEPTION-HARDENING-PLANS", "type": "operational_principle", "substantiation_type": "external_fact", "description": "Two written hardening plans capture the in-flight technical debt the operator has accepted as known: (a) the planned multi-step extraction of saudivault/detector.py into smaller modules with characterization-test guardrails and required frozen-benchmark passes between steps, and (b) the broad-exception review backlog covering catch-all blocks across api, saudivault, services, and scripts subsystems that need per-subsystem triage before being narrowed. Both documents are tracked plans, not completed remediations; surface them in the matrix to keep operator commitments visible to reviewers without overstating progress.", "coverage_gap": true, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [], "gap_severity": "medium" }, { "id": "HA.001", "type": "runtime_control", "substantiation_type": "dated_live_evidence", "description": "DNS A records for datasitr.com and api.datasitr.com were switched from the legacy single-VPS edge (8.213.18.247) to the ACK ingress (8.213.49.193) on 2026-05-04T01:12:50Z UTC. A 4-hour soak with periodic DNS, HTTPS, and certificate-chain re-checks passed without regression. On 2026-05-16, a scoped Alibaba Riyadh to GCP Dammam drill-standby exercise used a disposable drill hostname to validate DNS-level route switching, TLS-valid GKE Dammam standby service, evidence capture, and rollback. The drill does not widen this row into cross-cloud database replication, authoritative authentication failover, customer-data continuity, automatic failover, or active-active routing proof.", "coverage_gap": true, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 6, "implementing_regulation_refs": [], "gap_severity": "medium" }, { "id": "HA.002", "type": "routing_control", "substantiation_type": "external_fact", "description": "Customer traffic terminates at the ACK ingress controller, which is deployed across multiple availability zones in the Alibaba Cloud Riyadh (me-central-1) region. Topology is documented in docs/runbooks/sync-public-site-to-ack.md.", "coverage_gap": false, "has_tests": false, "test_count": 0, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "HA.003", "type": "runtime_control", "substantiation_type": "dated_live_evidence", "description": "ACK ingress serves valid Let's Encrypt R12 SAN certificate covering datasitr.com, www.datasitr.com, and api.datasitr.com (issued 2026-03-08, expires 2026-06-06). Manual renewal procedure documented; cert-manager DNS-01 automation tracked as a separate scheduled control.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "HA.004", "type": "runtime_control", "substantiation_type": "code_test", "description": "scripts/verify_public_route_ha_check.py exercises the customer DNS path through multiple resolvers, confirms IP resolution to ACK ingress, and validates HTTPS readiness on /readyz. Refuses to gate green if any check fails.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "HA.005", "type": "operational_principle", "substantiation_type": "dated_live_evidence", "description": "Cutover events are followed by a 4-hour soak with re-checks at T+15min, T+1h, T+2h, T+4h covering DNS resolution, HTTPS reachability, and certificate validity. Soak is signed separately from pre-soak so reviewers can distinguish initial flip from sustained operation.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 5, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SA-ID-CHECKSUM", "type": "runtime_control", "substantiation_type": "code_test", "description": "The isolated control-plane detector validates Saudi National ID and Iqama findings with the Saudi eHealth Core IS0001 Appendix B algorithm: ten numeric digits, citizen IDs beginning with 1, resident IDs beginning with 2, odd-position doubling, digit-sum normalization, and a modulo-10 final check digit. Invalid checksum matches are still surfaced but confidence is reduced instead of being treated as format-validated.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-PROVIDER-MODEL-ALLOWLIST-DEFAULT-DENY", "type": "runtime_control", "substantiation_type": "code_test", "description": "The isolated control-plane policy engine treats empty provider and model allowlists as no approved outbound AI destination. Clean requests fail closed unless both the requested provider and requested model are explicitly listed in the tenant policy.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-AUDIT-VERIFY-PARTIAL-JSON-BROKEN", "type": "runtime_control", "substantiation_type": "code_test", "description": "Control-plane audit verification handles a partial or corrupt JSONL flush defensively. Instead of raising from json.loads, verify_event_file returns status=broken, records the line number and invalid_json error, and preserves the last intact hash pointer for operator repair.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-AUDIT-APPEND-FAILURE-SYSTEM-TRAIL", "type": "runtime_control", "substantiation_type": "code_test", "description": "A primary policy-decision audit append failure no longer breaks the caller path in the isolated control-plane scaffold. The policy engine catches the failure, writes a minimized audit_append_failure record to a system audit trail, and returns an empty evidence pointer so the caller can continue without raw prompt leakage.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-PER-TENANT-AUDIT-CHAINS", "type": "runtime_control", "substantiation_type": "code_test", "description": "Control-plane audit events are written to tenant-scoped append-only hash chains under control_plane_audit//events.jsonl. Per-tenant exports include only that tenant's events and preserve a verifiable tenant chain instead of filtering a shared global chain.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-AUDIT-TENANT-MARKER-CHAIN", "type": "runtime_control", "substantiation_type": "code_test", "description": "A global control-plane marker chain records tenant_id, first_event_hash, last_event_hash, count, and last_updated after tenant event appends. Reviewers can verify that a tenant chain has not been replaced wholesale without exposing other tenants' event payloads.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-AUDIT-GLOBAL-CHAIN-MIGRATION", "type": "runtime_control", "substantiation_type": "code_test", "description": "A migration helper converts any pre-existing global control-plane events.jsonl into tenant-specific chains. The helper verifies the source chain before migration, rehashes each tenant chain in tenant-local order, writes tenant markers, archives the source file, and records minimized migration system events.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SHADOW-GATEWAY-HOOK", "type": "runtime_control", "substantiation_type": "code_test", "description": "The live gateway now invokes the enterprise control-plane policy engine in observe-only shadow mode after the existing three-lane decision and AUDIT-001 safety reroute have settled. The existing RouteDecision remains authoritative; the shadow path records evidence but does not change routing, provider selection, response status, or customer-visible behavior.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SHADOW-COMPARE-EVENT-MINIMIZATION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Each shadow evaluation writes a policy_shadow_compare event to the tenant control-plane audit chain with request ID, tenant ID, final live route, shadow action, reason codes, provider/model labels, detected sensitivity classes, and latency. The event stores a caller-computed SHA-256 digest through the policy decision path and does not store raw prompt text, provider tokens, OAuth tokens, cookies, or secret material.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SHADOW-FAILURE-ISOLATION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Shadow policy loading, evaluation, audit append, and metrics failures are isolated from customer requests. The helper returns a shadow_error result, writes a minimized policy_shadow_error system event when possible, and never raises back into the live gateway path.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SHADOW-DIVERGENCE-METRICS", "type": "runtime_control", "substantiation_type": "code_test", "description": "Shadow-mode comparisons append a minimized metrics row and expose a summary suitable for an operator dashboard tile: total shadow requests, agreement count, divergence count, error count, p95 latency, divergence-by-reason, and divergence-by-tenant. This supports pre-enforcement review without changing customer traffic.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SIGNED-POLICY-LOAD", "type": "runtime_control", "substantiation_type": "code_test", "description": "Tenant control-plane policies can be loaded through PolicyDocument.load_signed only after the plain JSON policy and its sidecar signature are validated. The signature sidecar records the policy hash, tenant ID, policy version, signing timestamp, Ed25519 key ID, and public-key fingerprint; load_signed fails closed on missing sidecars, malformed JSON, tenant/version mismatch, unsupported algorithms, and invalid signatures.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-SIGNED-POLICY-TAMPER-REJECT", "type": "runtime_control", "substantiation_type": "code_test", "description": "Signed tenant policy verification rejects payload tampering and signing-key mismatch before any policy body can be trusted by shadow or future enforcement paths. Policy JSON is canonicalized with sorted UTF-8 JSON before hashing, sidecar metadata is canonicalized before signature verification, and verification uses the current DataSitr Ed25519 public key fingerprint.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-POLICY-VERSION-BUMP-AUDIT", "type": "runtime_control", "substantiation_type": "code_test", "description": "Promotion of a signed tenant policy version emits a tenant-scoped policy_version_bumped audit event after signed-policy verification succeeds. The minimized payload records old version, new version, operator ID, approval reference, policy SHA-256, signing key ID, and timestamp without raw prompts, provider tokens, OAuth tokens, cookies, or customer PII.", "coverage_gap": false, "has_tests": true, "test_count": 1, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-EVENT-SCHEMA-ROUNDTRIP", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Phase 11a Breach Desk module defines a standalone BreachEvent schema matching the file-backed breach-register procedure. The schema validates the required register fields, conditional notification and closure fields, and the documented enum values without changing the existing production saudivault.breach ledger.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-DEADLINE-COUNTDOWN", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Phase 11a Breach Desk module computes the 72-calendar-hour authority notification deadline from detected_at in UTC and classifies open events as compliant, approaching, overdue, not_required, or completed. The implementation treats the deadline boundary itself as still compliant and marks only timestamps after the deadline as overdue.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-FILE-REGISTER-API", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Phase 11a Breach Desk module provides a file-backed Python API for creating, reading, updating, listing, and filtering BR-YYYY-MM-NNN.json breach records under a configurable register directory. Updates preserve fields not in the update payload, and active-list filtering excludes records closed with remediation_status=Completed and closed_at set.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-AUDIT-REGISTERED-EVENT", "type": "runtime_control", "substantiation_type": "code_test", "description": "Breach Desk register creation can emit a minimized breach_registered event into the tenant control-plane audit chain. The event records the breach ID, classification, severity, sensitive-data flag, affected tenants, detection timestamp, computed 72-hour notification deadline, and reporter without storing raw incident narrative text.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-AUDIT-72H-NOTIFICATION-PROOF", "type": "runtime_control", "substantiation_type": "code_test", "description": "When authority_notified_at first transitions from empty to a timestamp, Breach Desk emits a breach_authority_notified event with the notification status, notification timestamp, and computed hours_to_deadline. This creates a cryptographic proof point for the 72-hour notification timeline without auto-sending legal notices.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-AUDIT-STATE-TRANSITIONS", "type": "runtime_control", "substantiation_type": "code_test", "description": "Breach Desk update operations group register changes into logical lifecycle events for containment updates, subject notification, remediation status changes, and closure. A closure event records closed_at and full_duration_hours, while unrelated field refinements emit a generic breach_field_updated event with hashed old/new values instead of raw sensitive narrative text.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-AUDIT-TENANT-ISOLATION-SANITIZATION", "type": "runtime_control", "substantiation_type": "code_test", "description": "Breach Desk audit events are appended to affected tenant chains through AuditEventService, inherit per-tenant marker verification, and sanitize payloads before emission. Secret-like values are redacted, tampered breach_desk_event payloads break verification, and unaffected tenant chains remain empty.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-CLI-LIFECYCLE-COMMANDS", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Phase 11c Breach Desk CLI lets an operator create, update, close, report on, and inspect countdown state for synthetic or real breach register entries without writing Python. The CLI validates field names against the register schema, refuses closed-record updates unless --force is supplied, and stores records through BreachRegister so Phase 11a validation still applies.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-CLI-NOTIFICATION-RECORDING-NO-SEND", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Breach Desk CLI records authority and subject notifications after the operator sends them through an approved external channel. The command sets notification status and timestamps, emits the Phase 11b audit event, and prints a no-send boundary so the tool cannot be mistaken for an SDAIA or subject notification delivery mechanism.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-CLI-RUNBOOK-REPORT-COUNTDOWN", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Breach Desk CLI provides report and countdown views for operator review, with tenant/severity/breach filters, terminal-width trimming, NO_COLOR-safe countdown output, documented exit codes, backup guidance, and audit-chain verification instructions for interrupted sessions.", "coverage_gap": false, "has_tests": true, "test_count": 4, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-NOTIFICATION-DRAFT-AUTHORITY", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Phase 11d Breach Desk notification generator creates Arabic-authoritative and English-back-translation authority notification drafts aligned to the NDGP breach incident form. The CLI writes reviewable files only, emits a content-minimized breach_notification_drafted audit event, and does not submit to SDAIA or make a legal notifiability conclusion.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-NOTIFICATION-DRAFT-SUBJECT", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Breach Desk subject-notice draft generator creates Arabic-authoritative and English-back-translation subject notification drafts with practical self-protection guidance. The output is reviewable evidence for PDPL Article 24 workflows but remains operator-submitted and counsel-reviewed.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "BREACH-DESK-NOTIFICATION-GLOSSARY-VERIFIED", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Phase 11d generator uses a fixed canonical Arabic regulatory glossary for SDAIA/PDPL breach terms instead of ad hoc translation. English back-translation lines bracket their Arabic source so an operator who cannot read Arabic can verify every generated claim before submission.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "CONTROL-PLANE-MAIL-GUARD-METADATA-SCOPE", "type": "operational_principle", "substantiation_type": "code_test", "description": "The Google Workspace Mail Guard scaffold is documented as metadata-only until a future Phase 6 ADR selects a wider Gmail access model. The manifest retains least-privilege compose/add-on scopes, and the README no longer claims draft body scanning or attachment content scanning under draftAccess=METADATA.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 1, "implementing_regulation_refs": [] }, { "id": "COMPLIANCE-MATRIX-SDAIA-AI-ADOPTION-MAPPING", "type": "runtime_control", "substantiation_type": "code_test", "description": "Every control-matrix row carries a single best-fit SDAIA AI Adoption Framework pillar or an explicit null value when no AI Adoption pillar clearly applies. The YAML source includes reviewer-readable comments explaining each pillar choice, and private generated artifacts summarize pillar coverage for SDAIA accreditation evidence review.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "COMPLIANCE-MATRIX-NCA-CYBERSECURITY-MAPPING", "type": "runtime_control", "substantiation_type": "code_test", "description": "Every control-matrix row carries applicable NCA framework references for procurement review. Exact NCA sub-control identifiers are left null unless verified from canonical NCA source material, preventing false precision while still mapping controls to ECC, CCC, DCC, or an empty list when no clear NCA cybersecurity mapping exists. Private generated artifacts summarize the framework-reference coverage.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 3, "implementing_regulation_refs": [] }, { "id": "COST-OPTIMIZER-USAGE-TRACKING", "type": "runtime_control", "substantiation_type": "code_test", "description": "The Cost Optimizer records one tenant-scoped usage event per gateway result, including provider/model, lane, token counts, department, app, purpose, and the exact provider cost estimate captured from the existing billing/provider usage path.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "COST-OPTIMIZER-PSEUDONYMOUS-USER-HASH", "type": "runtime_control", "substantiation_type": "code_test", "description": "Cost Optimizer usage records identify users only through deterministic tenant-scoped HKDF-SHA256 pseudonyms. The same user is stable within a tenant for budget attribution, while the same real identifier in different tenants produces different hashes and cannot be correlated through the usage ledger.", "coverage_gap": false, "has_tests": true, "test_count": 2, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] }, { "id": "COST-OPTIMIZER-USAGE-AUDIT-EVENT-BUCKETED", "type": "runtime_control", "substantiation_type": "code_test", "description": "Each Cost Optimizer usage write emits a tenant-scoped control-plane audit event with only the request id, accounting period, and a coarse cost bucket. Exact cost values remain in the tenant usage ledger and are not duplicated into the tamper-evident audit chain.", "coverage_gap": false, "has_tests": true, "test_count": 3, "has_evidence_refs": true, "evidence_count": 2, "implementing_regulation_refs": [] } ] }