69 lines
2.3 KiB
Markdown
69 lines
2.3 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
|
|
|
|
## Does Not Own
|
|
|
|
- immutable audit log storage
|
|
- records retention engine
|
|
- inspection fieldwork
|
|
|
|
## 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.
|