DTCF normalises what an organization must achieve into 31 objectives across 10 families, then maps each to the frameworks practitioners face. Mappings are graded: fully addressed, partially addressed, or deliberately absent with the reason recorded. An empty cell is a finding about the framework, not a gap in your programme.
DTCF 2026.1 · published 10 Sep 2026 · CC BY 4.0 · free to use with attribution
A named individual is accountable for the digital trust programme, with the authority and budget to direct it.
Policies covering the organization's obligations are approved, dated, owned and reviewed on a stated cycle.
Security, privacy and compliance responsibilities are assigned and communicated to the people who hold them.
Risks to objectives are identified and assessed on a defined cadence and on material change.
Risks are recorded with inherent and residual judgement, an owner, a treatment decision and a review date.
Risk appetite is stated in terms someone can measure, with indicators and thresholds that trigger action.
Legal, regulatory and contractual obligations that apply are identified, owned and kept current.
What is in scope for each framework or certification is decided, justified and recorded, including deliberate exclusions.
People receive role-relevant training on joining and at a defined cadence, and completion is evidenced.
Data held is inventoried, classified and assigned an owner.
Data leaves the organization only through a decided channel, with a defined end and a record of what was shared.
Data is removed from primary systems, backups, caches, exports and third parties when it is no longer needed or on request.
Access is provisioned on a documented request, changed when a role changes and removed promptly on departure.
Entitlements are reviewed by someone who can judge them, with revocations tracked to completion.
Authentication is proportionate to risk, with multi-factor authentication on administrative and remote access.
Administrative access is limited, separately approved, monitored and time-bound where possible.
Changes to production are requested, reviewed, tested and recorded, with emergency changes reconciled afterwards.
Vulnerabilities are discovered, prioritised by risk and remediated within stated timeframes, with exceptions recorded.
Security-relevant events are logged, retained and reviewed, with alerts that reach a person who acts.
Devices with access to organizational data are hardened, patched, encrypted and recoverable.
Security requirements, review and testing are part of how software is built and released.
Third parties with access to data or systems are inventoried with an owner and a criticality judgement.
Third parties are assessed before onboarding and periodically thereafter, at a depth proportionate to what they touch.
Contracts carry security, privacy and breach terms, and access and data are recovered when the relationship ends.
An incident response plan exists, names roles, and is exercised.
Reportable incidents are assessed and notified to regulators and affected people within the applicable deadlines.
Backups exist, are protected from the same failure as production, and restoration is tested.
Critical processes have recovery objectives, a continuity plan and a tested route back to service.
Every control has one accountable owner and named performers for its tasks.
Controls are tested by someone other than the person who performs them, and results are reported without softening.
Findings carry an owner, a date, a remediation and evidence that the fix works.
First edition. Objectives are normalised statements of what an organization must achieve. Mappings are graded: full, partial, or a recorded absence with the reason it is absent. An empty cell is a finding about the framework, not about the objective.
Framework names and references are the property of their publishers. DTCF is an independent mapping and is not endorsed by them. Corrections are welcome through the contact form and are published in the edition changelog.