120 lines
4.9 KiB
Markdown
120 lines
4.9 KiB
Markdown
# Risk Compliance Domain Boundary
|
|
|
|
## Purpose
|
|
|
|
Risk and compliance workflows for data protection incidents, DPIAs, compliance controls, audit measures, risk registers, and internal-control evidence.
|
|
|
|
## Owns
|
|
|
|
- risk registers
|
|
- compliance controls
|
|
- DPIA records
|
|
- data protection incident records
|
|
- audit measures
|
|
- internal-control evidence
|
|
- immutable normalized sanctions-list snapshots
|
|
- version-pinned screening runs and candidate explanations
|
|
- reviewer dispositions, exceptions, and screening freshness
|
|
- block, review, and degraded screening-gate decisions
|
|
- reusable assurance relationships from obligation through governed object,
|
|
risk, control, evidence, finding, corrective measure, and effectiveness
|
|
review
|
|
|
|
## Does Not Own
|
|
|
|
- immutable audit log storage
|
|
- records retention engine
|
|
- inspection fieldwork
|
|
- domain-object lifecycle and corrective execution owned by the affected module
|
|
- policy rule evaluation or immutable audit-log storage
|
|
|
|
## Integration Candidates
|
|
|
|
- audit
|
|
- policy
|
|
- records
|
|
- inspections
|
|
- files
|
|
- tasks
|
|
- notifications
|
|
- connectors
|
|
|
|
## Sanctions Screening Contract
|
|
|
|
Connectors owns acquisition and raw source evidence. Risk Compliance imports an
|
|
exact connector snapshot, preserves its provenance, normalizes the list, and
|
|
owns every legal screening and review decision made from it.
|
|
|
|
The module provides the versioned
|
|
`risk_compliance.sanctions_screening` interface and
|
|
`riskCompliance.sanctionsScreeningProvider` capability. A consumer explicitly
|
|
submits:
|
|
|
|
- an immutable list snapshot
|
|
- an idempotency key
|
|
- the minimum subject data required for comparison
|
|
- matching limits and its `block`, `review`, or `degraded` failure policy
|
|
|
|
The response contains a stable `risk-screening:<run-id>` evidence reference and
|
|
a gate decision. Consumers can later check that evidence against a current
|
|
subject, an expected or latest source snapshot, and a current policy without
|
|
importing this module's internals.
|
|
|
|
Freshness reasons explicitly distinguish source replacement or age, subject
|
|
changes, matcher/normalization/policy changes, incomplete outcomes, and expired
|
|
or review-due dispositions. The reconciliation API lists the latest known
|
|
screening per subject that can already be proven stale. Subject changes remain
|
|
the consuming system's responsibility because Risk Compliance deliberately
|
|
stores immutable screening-time snapshots rather than owning each source
|
|
record.
|
|
|
|
Fuzzy candidates always require review. A confirmed match blocks; a set of
|
|
independently cleared false positives allows; source or execution uncertainty
|
|
uses the consuming module's configured failure policy.
|
|
|
|
## Horizontal Assurance Graph
|
|
|
|
Sanctions screening is the first complete assurance vertical, not the whole
|
|
module model. Risk Compliance persists the reusable graph:
|
|
|
|
```text
|
|
Obligation -> governed object -> risk -> control -> evidence -> finding -> measure -> effectiveness review
|
|
```
|
|
|
|
Every node and relationship has a stable tenant-local identity, immutable
|
|
revision history, effective and recorded time, owner and optional scope,
|
|
provenance, legal/policy/evidence references, and optimistic-concurrency
|
|
guards. Corrections create a new revision; the historical assertion is not
|
|
rewritten or deleted. Governed-object nodes retain only an opaque reference to
|
|
the object owned by another module.
|
|
|
|
The tenant API exposes bounded current-object listing, revision histories,
|
|
aggregate counts, and graph traversal. Traversal is intentionally limited to
|
|
eight relationships and 500 returned objects. Search indexes only current
|
|
revisions, rechecks tenant access at result time, and omits confidential
|
|
descriptions. Aggregate responses contain counts, never labels or opaque
|
|
references.
|
|
|
|
Completed sanctions screenings automatically project obligation, party,
|
|
exposure risk, version-pinned control, immutable evidence, and finding nodes.
|
|
This projection is idempotent and includes unsuccessful or stale screening
|
|
outcomes so operational uncertainty remains visible. The non-sanctions test
|
|
fixture proves the entire chain through corrective measure and effectiveness
|
|
review without coupling the graph to sanctions data.
|
|
|
|
Policy may advise or block based on assurance state; Audit records events;
|
|
Files/Records retain referenced evidence; Tasks/Workflow may coordinate review
|
|
and correction. Risk Compliance owns risk, control, finding, and effectiveness
|
|
semantics, but the affected domain module remains authoritative for its object
|
|
and corrective execution.
|
|
|
|
### Access, recovery, and retirement
|
|
|
|
Read, write, and administration use the Risk Compliance workspace scopes and
|
|
are always tenant-bound. Generated sanctions evidence additionally keeps the
|
|
sanctions permissions on its source workflow. Database backup and restore is
|
|
the recovery mechanism for the immutable graph; migration verification covers
|
|
both graph tables. Module retirement is destructive and therefore requires a
|
|
database snapshot before graph, source, screening, and review evidence is
|
|
removed.
|