Data security framework

Formalises the implicit security controls in the PDTF trust framework into a published security workstream: KYC/KYB for issuers, DID key management, signature verification, revocation handling, and audit logging — with a policy document, a checklist, and an audit profile per control.

1. Overview & scope

OPDA's published trust framework — the PDTF 2 Specification and its governance.md — already implies a comprehensive security posture. Issuer onboarding requires KYC/KYB; participants control DIDs whose key material must be managed; verifiers validate cryptographic proofs on Verifiable Credentials; revocation runs through a status list; and operational governance carries an accountability principle that presupposes audit trails. None of these is currently published as a named workstream with a policy, a checklist, and an audit profile.

This framework formalises five controls as that named workstream, on the commission given in ADR 0001 §"Wave 2 — Data Security framework". The controls themselves are not new; the discipline of publishing them with audit-grade artefacts is.

Purpose

• Formalise the implicit. The PDTF Spec, the governance document, and the compliance-and-policy-checklist.md name many of these controls in passing. This page consolidates them under one named framework so that members, regulators, and auditors can find them in one place.
• Fill DMBOK KA #5. ADR 0001 flags Data Security as a weakness — present at the crypto layer (VC signatures, did:web) but without a policy framework around it. This page is the framework.
• Anchor the Accreditation Directory. Per ADR 0004, firms self-score on capability axes. Data Security is one of those capabilities; the five controls below are how a firm proves it.

Regulatory anchor

UK GDPR Article 32 ("Security of processing") is the statutory floor for every PDTF participant. Article 32(1) requires controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk", and explicitly names encryption, integrity, availability, and regular testing of the effectiveness of those measures. The five controls in this framework operationalise Article 32 for the specific shape of the PDTF ecosystem.

Article 33 ("Notification of a personal data breach to the supervisory authority") sets the 72-hour ICO notification window referenced in §5 Incident response. Article 5(1)(f) ("integrity and confidentiality") underpins the cryptographic primitives that controls 2 and 3 rely on. The compliance-and-policy-checklist.md names UK GDPR compliance, ICO 72-hour breach notification, and ISO 27001 (or equivalent) as baseline requirements; this framework lifts those out of the checklist and gives them per-control structure.

The five controls

The scope of this framework is the five controls listed in §2. Out of scope: sector-specific compliance regimes a member firm is independently subject to (SRA Code of Conduct, RICS Rules, FCA Handbook, ICO codes of practice), commercial cyber-insurance products, and the operational security of the OPDA Knowledge Base itself (a separate governance question covered indirectly under ADR 0001 Wave 3).

2. The five controls

The order matches the existing stub on this page and the order in governance.md §2.A "Onboarding Policies" and §"Technical Layer". Each control has the same five-part structure: scope, technical anchor, required artefacts, audit profile, common failure modes.

2.1 Issuer onboarding KYC/KYB

Brief, because this control is covered in depth on Conformance scheme.

Scope

Verifying the legal identity of a candidate Accredited Issuer before its DID is added to the Trust Registry. Per governance.md §2.A: "Verified organizations (e.g., land registries, surveyors) allowed to issue property VCs. Must pass onboarding and legal agreements." Onboarding is itself enumerated in the same section as "KYC/KYB verification of the entity; Signed legal agreement; DID registration in Trust Registry."

Out of scope here: the eligibility criteria, scoring rubric, and 80% pass mark — those live on Conformance scheme Tier A. This control covers the security properties of the onboarding artefacts (identity evidence, signed agreement, key publication).

Technical anchor

The Accreditation Policy and the Non-Compliant Member Policy are the primary anchors. ISO 27001 (or industry equivalent) is named as the security baseline in clause 10 of the Accreditation Policy and clause 7 of the Accreditation Scheme — see Conformance scheme — standards and conduct expectations.

Required artefacts

• Entity identity evidence pack — Companies House (or equivalent) record, beneficial-ownership disclosure, registered office confirmation, regulator-issued IDs where applicable (SRA, RICS, FCA).
• Signed Trust Framework participation agreement — per governance.md §2.C "Terms of Use: GA → Issuers".
• ISO 27001 certificate or equivalent evidence — per compliance-and-policy-checklist.md §"Information Security".
• Initial DID publication record — proof that the issuer controls the DID being added to the Trust Registry (signed challenge response, demonstrated via the mechanism in §2.3).

Audit profile

The Tier A independent review panel (three reviewers, 80% pass mark — see Conformance scheme review panel) is the existing audit. Annual self-reassessment, plus random audits per clause 7 of the Accreditation Policy. No additional audit cadence is created by this framework for control 1.

Common failure modes

• Stale identity evidence. KYC/KYB packs age out; beneficial ownership changes; the entity restructures. Annual re-attestation is the existing mitigation; auditors should sample.
• Mis-attribution of DID control. A candidate issuer presents a DID it does not in fact control. Mitigated by a live challenge-response at onboarding (per Draft_ PDTF Participant DID Auth OAuth 2 Specification.md §4).
• ISO 27001 scope mismatch. A certificate exists but excludes the systems that handle PDTF claims. Auditors should check the Statement of Applicability scope, not just the certificate.

2.2 DID key management

Scope

The full key lifecycle for each issuer's signing keys: generation, publication via the DID document, rotation, retirement, and recovery. Applies to all DIDs registered in the Trust Registry, and to any DIDs used by trusted proxies (per PDTF 2 Specification §"Trust Model": "trusted proxies that can be relied on to connect to non-compliant sources of data and accurately issue them as VCs into the ecosystem").

Out of scope: participant DIDs generated by PDTF-compliant platforms for end users (Sellers, Buyers, Conveyancers acting in a transaction). Those keys are managed by the participant's platform under its own policies; this framework covers issuer keys, not platform-managed participant keys.

Technical anchor

The PDTF Spec specifies did:key for simple participant DIDs and did:web for "more flexible participant DIDs or for transactions, which need to describe service endpoints" (PDTF 2 Spec §"Core Technologies — Decentralized Identifiers"). Implementers must support universal DID resolution to handle other methods (same section). Issuer DIDs in the Trust Registry are normatively did:web — they need to publish key material via an HTTPS endpoint that the framework repository can reference.

The Draft_ PDTF Participant DID Auth OAuth 2 Specification.md defines the challenge-response flow that exercises issuer keys at authentication time (§4 "Protocol Flow"). The example signature suite named in §4 step 3 is Ed25519Signature2020; the PDTF 2 Spec references the W3C Data Integrity model more broadly (PDTF 2 Spec §"PDTF Verifiable Credentials" — "A proof property that represents an embedded proof (digital signature) in accordance with the VC Data Integrity spec, of type DataIntegrityProof and proofPurpose of assertionMethod").

Underlying standards: W3C Decentralized Identifiers v1.0; the did:web method specification; W3C Verifiable Credential Data Integrity v1.0.

Required artefacts

• Key generation record. Date, environment (HSM, secure enclave, software), algorithm and key size, the public key fingerprint that ends up in the DID document.
• Published DID document at the issuer's .well-known/did.json endpoint, listing every active verification method. Must be served over HTTPS with a valid TLS certificate (did:web inherits its trust from web PKI).
• Key rotation log. Each rotation event recorded with the prior key fingerprint, the new key fingerprint, the date, and the rotation reason (scheduled, suspected compromise, personnel change, algorithm migration).
• Key custody policy. Who holds the private key material, under what access controls, with what break-glass procedure.
• Retirement procedure. How a retired key is marked in the DID document (verification method removed; revoked status carried in any VCs still signed by it).

Audit profile

• Live DID-document resolution. Auditor resolves the issuer's did:web from the published Trust Registry entry and confirms the verification methods match the issuer's declared key inventory.
• Rotation-log walkthrough. For each rotation in the audit period, evidence that the published DID document was updated and that VCs issued under the prior key remain verifiable (or are revoked).
• Custody-control sampling. Confirm private-key access is limited to the named role holders in the key custody policy, and that the access log is preserved.
• HSM / secure-enclave attestation where the policy requires hardware-backed key storage.

Common failure modes

• Private key checked into source control. The classic incident. did:web makes this particularly visible because the public counterpart sits at a well-known path; commit history exposure is immediate.
• DID document and key inventory drift. Internal rotation happens without updating the published DID document; or the DID document lists keys that have been retired internally. Verifiers then accept stale signatures.
• TLS misconfiguration on the did:web endpoint. Expired certificate, mismatched hostname, weak cipher suite. did:web trust is entirely PKI-derived; the security of the DID document is the security of the TLS connection that serves it.

2.3 Signature verification

Scope

The Verifier's responsibility when accepting a PDTF Verifiable Credential: validating the embedded cryptographic proof, resolving the issuer DID, confirming the issuer is in the Trust Registry with active status, and checking that the claim has not been revoked (covered in detail under §2.4). This control defines what counts as "verified" for the purposes of the framework.

Technical anchor

Per PDTF 2 Specification §"PDTF Verifiable Credentials":

A proof property that represents an embedded proof (digital signature) in accordance with the VC Data Integrity spec, of type DataIntegrityProof and proofPurpose of assertionMethod.

The PDTF Spec lists W3C Verifiable Credentials Data Model v2.0, Verifiable Credential Data Integrity v1.0, and JSON-LD v1.1 as the underlying standards (PDTF 2 Spec §"Introduction"). Linked Data Proofs and JWS are both named in governance.md §2.B "Technical Layer" as acceptable proof mechanisms.

The Trust Registry itself is the authority on issuer status. From governance.md §4:

Public JSON-LD document containing: Issuer DID, Organization legal name, Status (active/revoked), Credential types authorized — signed by Governance Authority for authenticity.

Required artefacts

• Verifier procedure document. The verifier's published procedure for accepting a PDTF VC: signature algorithm support matrix, DID resolution mechanism, Trust Registry consumption, status-list consumption, error handling.
• Verification log. For each VC presented to the verifier and either accepted or rejected: timestamp, issuer DID, credential type, verification outcome, failure reason if rejected. (See also control 5.)
• Trust Registry cache policy. How often the verifier re-pulls the signed Trust Registry document; how it handles network failures fetching the registry; whether it permits offline use.

Audit profile

• End-to-end test. Present a known-good VC and a known-bad VC (revoked / tampered / signed by an out-of-registry DID) to the verifier; confirm correct outcomes.
• Algorithm-support inspection. The verifier supports all signature suites named in the issuer's published DID documents.
• Registry-cache walkthrough. Confirm the verifier's Trust Registry consumption matches the documented cache policy and that stale-registry handling does not silently downgrade to "trust all DIDs".

Common failure modes

• Signature checked, issuer not. The verifier confirms the JWS is valid but does not confirm the signing DID is in the (current) Trust Registry. A revoked issuer's signatures still verify cryptographically.
• JSON-LD context substitution. The verifier resolves a JSON-LD @context URL at verification time without pinning or caching, and a malicious server returns a substituted context. Mitigation: cache verified contexts; pin by hash where the PDTF context vocabulary is stable.
• Confusion of issuer DID and subject DID. The credentialSubject DID is treated as if it were the issuer DID. Verifiers must check signature against the issuer property, which (per PDTF 2 Spec §"PDTF Verifiable Credentials") "must contain the DID of the data source (trusted primary source, trusted proxy or participant)".

2.4 Revocation handling

Scope

Mechanics of revoking a previously-issued VC: the status-list mechanism, publication of revocations, propagation to verifiers, and the relationship between per-VC revocation and Trust Registry status changes for the issuing DID.

Technical anchor

Per governance.md §2.B "Technical Layer": "Revocation: Status List 2021 or equivalent." The PDTF 2 Specification normatively references W3C Bitstring Status List v1.1 (PDTF 2 Spec §"Introduction"). The spec also flags (§"Interoperability — Credential revocation"): "especially in relation to participant relationship credentials, so that the seller or buyer can control access to the data".

Two revocation paths exist and must be distinguished:

• Per-VC revocation via the issuer's published status list (Bitstring Status List). Revokes one specific credential without affecting other credentials issued by the same DID.
• Issuer-level revocation via the Trust Registry. The GA changes the issuer's status to "revoked" in the signed JSON-LD registry document, invalidating all credentials issued by that DID prospectively. Per governance.md §4 the registry carries per-DID status (active/revoked).

Required artefacts

• Status list publication endpoint per issuer DID. The endpoint URL is named in the issued VC; the document is itself a signed VC of type StatusList2021Credential (or its Bitstring Status List successor).
• Revocation event log. Each revocation event with credential ID, revocation reason, requesting party, authorising party, timestamp.
• Subject-request handling procedure. How a data subject requests revocation of a credential about them (notably for participant relationship credentials, per PDTF 2 Spec §"Interoperability — Credential revocation").

Audit profile

• Publication-cadence check. The status list document is refreshed at the documented cadence; ETag / Last-Modified headers are correct; signature on the status list is current.
• Trace a sample revocation end-to-end: subject request → internal authorisation → status-list update → verifier observes revoked status.
• Trust Registry interlock. When an issuer is revoked at the registry level, downstream verifiers stop accepting its credentials within the documented propagation window.

Common failure modes

• Stale status list. The issuer's status list endpoint serves an old document past its declared expiry; verifiers either accept the stale document (under-revocation) or refuse all credentials (over-revocation).
• Status list not signed. The status-list document is itself a VC and must carry a valid signature from the issuer. Verifiers that don't check this can be misled by a tampered list.
• Revocation requested but not effected. Data subject requests revocation; the request is logged but the status-list bit is never flipped. Mitigation: an audit trail per request, with the status-list update event as the closing artefact.

2.5 Audit logging

Scope

The set of events each participant MUST log; where logs live; for how long; and the integrity properties of the log itself. Audit logging is the connective tissue under the other four controls: every onboarding, key rotation, signature verification, revocation, and access decision leaves a record.

Technical anchor

The compliance-and-policy-checklist.md §"Audit and Monitoring" already requires participants to evidence "Regular Compliance Audits", a "Non-Compliance Log", and "Monitoring of Data Sharing Activities". The PDTF governance principles in governance.md §1 name Accountability as one of seven principles, which presupposes recorded evidence of who did what when.

UK GDPR Article 30 ("Records of processing activities") requires controllers to maintain records of processing operations under their responsibility. PDTF participants who act as controllers (which is most of them, in respect of the PII inside PDTF claims) are statutorily required to keep these records; this control formalises the PDTF-specific event set.

Required event set

At minimum the following events MUST be logged by each participant in whose system the event occurs:

• Issuance events — VC ID, credential type, issuer DID, subject DID, claim summary (path or hash, not full claim values for PII reasons), evidence references, timestamp.
• Verification events — VC ID presented, verifier identity, outcome (accepted / rejected with reason), timestamp.
• Revocation events — VC ID, revocation reason, authorising party, timestamp. Also: Trust Registry status changes affecting the participant.
• Key lifecycle events — generation, publication, rotation, retirement; algorithm, key fingerprint, authorising party, timestamp.
• KYC/KYB events — initial onboarding evidence submission, annual re-attestation, beneficial-ownership changes, policy updates.
• Access events — successful and failed authentication to systems that handle PDTF claims; particularly OAuth2 token issuance per the Draft_ PDTF Participant DID Auth OAuth 2 Specification.md flow.

Required properties of the log

• Integrity. Logs must be tamper-evident. Acceptable mechanisms include hash chains, append-only storage with retention locks, or signed periodic digests.
• Availability for audit. Logs must be producible on request by an OPDA-recognised auditor within a defined response window.
• Minimisation. Logs are themselves processing of personal data and are subject to UK GDPR. Don't log full claim payloads where a reference would suffice; don't log raw biometric or sensitive-category data.

Audit profile

• Coverage sampling. For each event class, the auditor picks a random business operation in the period and confirms the corresponding log record exists with the required fields.
• Integrity check. The auditor verifies the tamper-evidence mechanism (hash chain continuity, signed digest verification, retention-lock policy on the storage tier).
• Retention check. Logs from the start of the audit period are still present, complete, and readable.

Common failure modes

• Logs without integrity. The participant logs everything but to mutable storage; an insider can edit history.
• PII in logs. Logging the full credential payload puts personal data in a place that probably has weaker access controls than the primary store.
• Logs but no log review. Logs exist; no one ever looks at them. The compliance-and-policy-checklist.md §"Audit and Monitoring" calls out "Regular Compliance Audits" for this reason.

3. Mapping to Assurance Levels

The four PDTF Assurance Levels (AL1–AL4, per governance.md §5) describe the trust attached to a claim; the five security controls describe the operational discipline of a participant. The higher the AL the issuer asserts on its claims, the stronger the operational discipline the framework expects.

The table below is a proposed mapping for WG ratification. The intent is that controls are required on a sliding scale rather than appearing all-or-nothing at any one tier.

Definitions: Required — auditor must find evidence in the audit period or the AL claim is not supported. Recommended — auditor notes presence/absence; absence does not invalidate the AL claim. Out of scope — control does not apply at this AL.

4. Policy / checklist / audit framing

Per ADR 0001 Wave 2: each control is to receive "policy + checklist + audit profile". That three-part structure is what makes the framework auditable rather than aspirational.

4.1 Policy

The Policy layer is the published rule: what the framework requires. The starting point is the existing compliance-and-policy-checklist.md, which already names:

• Data Protection and Privacy — Privacy Policy, Data Protection Policy, Data Protection Legislation Compliance Framework, Data Breach Response Plan (with the ICO 72-hour clock), Data Retention and Disposal Policy.
• Information Security — Cybersecurity Policy, Business Continuity Plan, Incident Response Plan, Access Control Policy, ISO 27001 (or Cyber Essentials equivalent).
• Operational Policies — Risk Management, Supplier and Partner Assurance, Version Control and Change Management, Anti-Bribery (Bribery Act 2010).
• Training and Awareness — staff training on data protection, cybersecurity, anti-bribery.
• Audit and Monitoring — Regular Compliance Audits, Non-Compliance Log, Monitoring of Data Sharing Activities.

The Code of Conduct 2026.pdf sits alongside the checklist as the principles document. The Data Security framework Policy is the combination of those two documents, re-organised around the five controls, with the WG decisions in this page baked in.

4.2 Checklist

The Checklist is the per-firm self-assessment instrument: a structured questionnaire derived from the Policy, sized so a security officer can complete it in a defined time window. Proposed structure for WG authoring (not the items themselves — that is C&R WG work):

• One section per control (five sections). Each section asks: is the control in scope for our AL claim? What artefacts do we hold? When was the last review of each artefact?
• Evidence-tier alignment. Per ADR 0004 the Accreditation Directory uses three evidence tiers (self-asserted at 1–2, artefact-linked at 3–4, independently audited at 5–6). Each checklist item carries an evidence-tier indicator so the firm sees the gap between its current state and a higher tier.
• Cross-references to the Policy. Each checklist item cites the clause of the Policy it implements; ambiguous items are flagged for WG attention rather than left to firm interpretation.
• Annual cadence. Aligns with the Accreditation Policy's existing annual self-reassessment (clause 16) so a firm doesn't run two separate annual cycles.

4.3 Audit

Audit is the independent-verification layer. Two distinct audit consumers exist:

• The Accreditation Directory. Firms claiming evidence-tier 5–6 on the Data Security capability per ADR 0004 must hold an independent audit attestation. The audit profile per control in §2 above is the basis on which an OPDA-listed audit partner produces that attestation.
• The Conformance Scheme review board. The Tier A three-reviewer panel (Conformance scheme review panel) covers the KYC/KYB control by way of the existing onboarding pack; the other four controls are not within that panel's scope today and would require either an extension of the panel's remit or routing through an audit partner.

Who runs audits. A list of OPDA-recognised audit partners is contemplated in ADR 0004 for evidence-tier 5–6 attestations on capability claims; the same partners cover the audit profiles in this framework.

Cadence. Annual at minimum (aligned with the existing Accreditation Policy annual self-reassessment). Mid-cycle audits are triggered by: a reported incident affecting the firm; a Trust Registry status change; promotion of a previously-recommended control to required at a given AL.

Findings flow. Audit findings flow back into the Accreditation Directory as the per-firm capability score on Data Security. Material findings that affect a firm's AL claim or its Trust Registry status are routed through the Non-Compliant Member Policy 12-step framework — see Conformance scheme — non-compliance handling.

5. Incident response

Incident response is the procedural layer that activates when a control fails. The compliance-and-policy-checklist.md §"Information Security" already requires participants to maintain an Incident Response Plan and §"Data Protection and Privacy" requires a Data Breach Response Plan with the ICO 72-hour clock. This framework adds the PDTF-specific phases that sit on top of those firm-level documents.

Five phases

1. Detection. Indicators include: anomalous signature verification failures, key-custody alerts, unexpected DID-document changes, revocation-request surges, audit-log integrity warnings. Detection responsibility sits with whichever participant first observes the indicator.
2. Containment. Isolate the affected systems; if a key is suspected compromised, initiate emergency rotation per the control 2 procedure; if an issuer is suspected compromised, request urgent Trust Registry status change from the GA.
3. Notification.
   • ICO — within 72 hours of becoming aware of a personal-data breach, where the breach is likely to result in risk to the rights and freedoms of natural persons. UK GDPR Article 33(1) is the statutory anchor.
   • Affected data subjects — without undue delay where the breach is likely to result in a high risk to the rights and freedoms of natural persons. UK GDPR Article 34 is the statutory anchor.
   • OPDA Governance Authority — incident report to the C&R WG, on a timeline to be ratified by the WG. This is an OPDA-specific obligation in addition to the statutory ICO and subject notification.
   • Counterparty participants — for incidents that affect VCs already in circulation, the issuer must notify verifiers and holders known to have consumed the affected credentials.
4. Remediation. Revoke affected VCs (control 4), rotate keys (control 2), publish updated DID document (control 2), and refresh the Trust Registry entry. Record every step in the audit log (control 5).
5. Review. Post-incident review producing a written report, shared with the C&R WG, with lessons-learned that flow back into the framework. Repeated or systemic findings trigger re-opening the relevant control.

Cross-reference. Incident-driven liability questions (who is liable when a verifier relies on a compromised VC, who is liable when an issuer's key is compromised, etc.) sit on Risk & liability. This framework defines the operational response; the liability framework defines who bears the loss.

6. Governance, roles, and review

Roles below are read from governance.md §2.A (business-layer roles) and §3 (operational governance roles), with framework-specific responsibilities added.

Role responsibilities

Review cadence

• Annual framework review by the C&R WG, aligned with the existing annual scheme review (Accreditation Policy clause 19, Accreditation Scheme clause 13). Output: a Change Log appended to this page plus, where the changes are material, a new ADR.
• Standing item on quarterly C&R WG agenda — open incidents, outstanding audit findings, control changes proposed by member firms.
• Triggered review after any incident classified high or critical, after any change to the underlying W3C standards referenced in §2.2 and §2.3, or after a Trust Registry breach.

7. Open questions for WG kick-off

1. HSM mandate at AL3. Should hardware-backed key storage be required at AL3 (and not just recommended)? Implications: raises the bar for AL3 issuers, potentially excludes smaller surveyors and conveyancers who can credibly issue intermediate-trust claims today.
2. AL4 sufficiency for statutory authorities. How does the framework recognise that an AL4 official primary authority (HMLR, Companies House if it ever issued PDTF claims, local authorities for council-tax claims) operates under its own statutory security regime that already satisfies most of these controls? Should the framework define a deemed-compliance path rather than asking HMLR to fill out a Checklist?
3. Status-list publication cadence. Per the WG decision callout in §2.4, what is the SLA? The market expectation may be sub-hourly; the cost-to-issuer implication for hourly re-signing of status lists is non-trivial.
4. Audit-partner selection. ADR 0004 contemplates an OPDA-listed audit-partner panel for evidence-tier 5–6. How is that panel constituted, on what criteria, and how is conflict-of-interest managed for partners who also member-firm-consult to the firms they audit?
5. Cross-recognition of existing security regimes. A firm with ISO 27001, SOC 2 Type II, and Cyber Essentials Plus should not have to re-evidence the same controls under three labels. How does the framework recognise existing attestations as partial-or-full satisfaction of the audit profiles in §2?

Related

• Data quality framework — sibling workstream; DQ accuracy/consistency dimensions overlap with security data-integrity controls.
• Accreditation Directory — where security capability scores are reported.
• Conformance scheme — the binary compliance regime this framework extends; covers KYC/KYB onboarding in depth.
• Risk & liability — where compromise of a control flows in terms of who bears the loss.
• Overlay attachments — sibling Wave 2 workstream; attachment integrity is a verification concern that intersects this framework.

DAMA KA rubric — Wave 1 alignment

Per ADR 0001 Wave 1, KA-tagged pages follow a consistent rubric: Purpose · Activities · Deliverables · Roles · Metrics · Maturity. Sections below may be filled incrementally by Compliance & Risk WG — content authored above already maps to several of these; this scaffold is for the gaps.