Quick Read

SPK DDMS2000:2026 requires organisations to build and maintain an Applicable Obligations Register that formally documents all mandatory and voluntary due diligence obligations applicable to their operations by jurisdiction and subject type, shifting the compliance burden from the standard itself to the organisation's own documented legal position. Certification audits whether the register exists, is current, and is being followed in practice—not whether the underlying legal conclusions are correct—making it a first-class auditable artefact rather than a background assumption. The Position Statement field within each register entry is the most commonly under-built component and represents the critical point where most registers fail independent review.

Why This Whitepaper Exists

Every other requirement in SPK DDMS2000:2026 depends, at some level, on Section 6.1. The Applicable Obligations Register is the mechanism the standard uses to resolve what could otherwise be an impossible problem: writing one due diligence standard that has to work for organisations facing entirely different legal obligations, in different jurisdictions, across different sectors, without becoming obsolete the moment any one of those laws changes. This whitepaper sets out what the standard requires of the register in full, and how to build one that holds up under independent review rather than one that exists mainly to be filed and forgotten.

This standard does not tell the organisation what the law requires. It requires the organisation to know what the law requires, declare that position formally, and execute consistently against its own declaration. Certification tests whether the Applicable Obligations Register exists, is current, and is being followed in practice — not whether the underlying legal position is correct.

The Foundational Design Choice

SPK DDMS2000:2026 is deliberately law-agnostic. It does not enumerate every jurisdiction's anti-bribery law, every country's AML regime, or every region's forced labour statute — doing so would make the standard obsolete the moment any one of those laws changed, and would require constant revision to stay current across the dozens of jurisdictions a typical organisation might operate in. Instead, Section 6.1.1 requires the organisation to identify and document all obligations applicable to its due diligence activity, by subject type and jurisdiction, classified as mandatory obligations — laws, regulations, and binding requirements — and voluntary obligations the organisation has chosen to adopt.

This is the same discipline other management system standards apply to legal compliance generally, but SPK DDMS2000:2026 makes the register itself a first-class, auditable artefact rather than a background assumption sitting behind the standard's other requirements. Certification does not test whether the organisation's legal conclusions are correct — that is not a determination an assessor is positioned to make, since it requires jurisdiction-specific legal expertise the standard deliberately does not assume — it tests whether the register exists, is current, and is genuinely being followed in practice, which is a fundamentally different and more tractable question.

What Belongs in Every Entry

Section 6.1.3 sets out exactly what must be recorded for each obligation, and it is worth treating each field as a distinct discipline rather than a single checklist item.

Register field

What it must capture

Source, nature, jurisdiction

The specific law, regulation, or voluntary framework, and the jurisdiction(s) in which it applies

Subject type(s) and module(s) governed

Which of the standard's modules under Section 10 this obligation relates to, and which subject types it covers

Position Statement

What the organisation will and will not collect, verify, retain, or act upon, and why

Legal basis or justification

The statutory requirement, proportionality assessment, consent basis, or contractual requirement underlying the position

Ownership

Who approved the position and is accountable for it

Review cadence

When the position is next due for review, and what triggers an earlier review

Why the Position Statement is where most registers actually fail

The Position Statement is the field most often under-built in practice. A register entry that simply names a law — “GDPR applies” — without recording what the organisation has actually decided to do about it does not satisfy Section 6.1.3. Naming a law is a research task; writing a Position Statement is a decision. The distinction matters because the Position Statement, not the underlying law itself, is the document an analyst is actually expected to follow day to day. An analyst handling a personal data question does not, and should not, be expected to independently interpret GDPR from first principles — they follow the organisation's own documented position, which is why that position has to actually exist, in enough detail to be operational rather than aspirational.

Why ownership has to be a named individual, not a function

“Legal team” is not adequate ownership under Section 6.1.3. The clause requires accountability for the position, which means a named individual whose responsibility it is to have approved the position and to answer for it if questioned — not a department that could, in principle, be asked about it. This distinction becomes important precisely when a position is challenged: an organisation needs to be able to say who made this call, not only which function it came from.

Do Not Assume by Analogy

Section 6.1.2 addresses a specific and common failure mode directly: assuming an obligation is inapplicable because the organisation falls below the threshold of a different, unrelated regime. The clause is explicit that thresholds vary materially between regimes even within the same regulatory family, citing the contrast between CSDDD's narrowed, high threshold and the EU Forced Labour Regulation's complete absence of one, addressed in depth elsewhere in this series. Every entry in the register should be assessed on that specific obligation's own terms — never inherited from a conclusion reached about a different law, however closely related the two regimes might appear on the surface.

This principle generalises beyond the EU examples the standard itself uses. An organisation that has concluded it is out of scope for one jurisdiction's AML threshold should not assume the same conclusion holds for a neighbouring jurisdiction's regime, even where the two laws address similar subject matter — thresholds, definitions, and scope carve-outs rarely align exactly across jurisdictions, and the register needs an entry, and a conclusion, for each obligation independently assessed.

Keeping the Register Alive

Section 6.1.4 requires the register to be reviewed and updated at least annually, and whenever the organisation enters new jurisdictions, takes on new subject types, or when applicable regulations change materially — including changes tracked in the standard's own Annex D — with changes reported to the governing body. A register that was built once, at initial DDMS implementation, and has not been revisited since is not a functioning register under this standard; it is a historical snapshot, and treating it as current when it is not is itself a gap against Section 6.1.4, independent of whether the underlying legal conclusions happen to still be correct by coincidence.

This connects directly to the general ongoing due diligence obligation established at Section 10.24 elsewhere in this standard: just as individual subject-level conclusions have a shelf life, so does the organisation's own understanding of what obligations apply to it. A material regulatory change — the kind tracked in Annex D — is one of the event-based triggers that should prompt both a register update and, where relevant, a review of affected subjects' re-screening cadence under Section 10.24.2. The two obligations reinforce each other: a stale register can leave a subject's re-screening cadence calibrated to a legal position that no longer holds.

The Register as the Scoping Input, Not a Downstream Record

Section 6.1.3 requires the register to serve as the primary input to scoping the modules under Section 10 and the risk appetite determination under Section 6.6. This ordering matters. The register is not a compliance artefact sitting alongside the DDMS, produced after the organisation has already decided what its DDMS covers — it is the document that actually determines which modules apply, which subject types are in scope, and how the organisation's risk appetite gets set. A register built after the fact, to retroactively justify a scope the organisation had already decided on for other reasons, inverts the relationship the standard intends, and an assessor reviewing the register's history against the scope determination's history can often detect exactly this inversion from the dates alone.

Building the Register in Practice

Assign a register owner distinct from the individual obligation owners

While each Position Statement needs its own named owner, the register as a whole benefits from a single accountable owner responsible for its completeness and currency — someone whose role is to notice when a new jurisdiction, subject type, or regulatory change should trigger a new entry, rather than relying on each functional owner to proactively flag their own gaps.

Version the register, not just its individual entries

Consistent with the version control requirements addressed elsewhere in this standard, the register's own change history — when an entry was added, amended, or superseded, and why — should itself be retained, so the organisation can reconstruct what its documented legal position was at any point in time, not only what it is today.

Build the annual review as a genuine re-assessment, not a renewal stamp

An annual review that simply confirms each entry's review date without re-examining whether the underlying conclusion still holds does not satisfy the spirit of Section 6.1.4. The review should specifically test each entry against current regulatory status, not merely refresh its timestamp.

Common Misconceptions Worth Correcting

  • “A register entry just needs to name the applicable law.” Section 6.1.3 requires a full Position Statement, legal basis, ownership, and review cadence — not a citation alone.

  • “If we're out of scope for one jurisdiction's version of a law, we're probably out of scope for similar laws elsewhere.” Each obligation must be assessed on its own terms; thresholds and scope rarely align exactly across jurisdictions.

  • “The register is a compliance record we maintain after deciding our DDMS scope.” The register is meant to be the primary input to scope determination, not a downstream justification for a scope already decided.

  • “An annual review means confirming the entry is still there.” The review needs to re-test whether the underlying legal conclusion still holds, not merely refresh a timestamp.

Common Gaps Worth Checking

  • Register entries name the applicable law but contain no documented Position Statement describing what the organisation has actually decided to do.

  • An obligation was ruled out of scope by analogy to a different regime's threshold, with no independent assessment of its own terms.

  • The register has not been reviewed in the past 12 months, despite material regulatory changes tracked in Annex D.

  • Module scope under Section 5.2 was determined independently of the register, rather than derived from it, and the dates suggest the register was built retroactively.

  • Ownership is recorded at the functional or team level rather than assigned to a named, accountable individual.

  • No single owner is accountable for the register's overall completeness, leaving gaps in coverage that no individual Position Statement owner would be positioned to notice.

How Speeki Sentinel Certification Assesses This

Certification against SPK DDMS2000:2026 tests the register directly: whether entries contain genuine Position Statements rather than bare legal citations, whether the review cadence has actually been followed with genuine re-assessment rather than timestamp renewal, and whether the organisation's module scope traces back to register entries rather than existing independently of them. A register that exists but has never driven an actual scoping or risk appetite decision is treated as a gap against Section 6.1, regardless of how complete it looks on paper.

Speeki Sentinel is the certification product through which this assessment is delivered. Organisations may build and maintain their own Applicable Obligations Register independently of Sentinel; certification is a separate, optional step available once an organisation believes its register is ready to be independently tested.

Speeki is an accredited certification body. For current information on the specific accreditations Speeki holds and their scope, please refer to speeki.com rather than relying on this whitepaper, as accreditation status and scope are maintained centrally and can change.

Closing Note

The Applicable Obligations Register is where SPK DDMS2000:2026 stops being a generic template and becomes an organisation's own, specific answer to its own, specific legal exposure. A register built once and never revisited is a snapshot of a decision an organisation made at a point in time that has since moved on. A register genuinely maintained — owned, reviewed, and actually driving the DDMS's scope rather than following it — is the document that keeps the rest of the standard pointed at the right target as both the law and the organisation itself continue to change.