Compliance controls and risk coverage
Version an obligation-to-control register, independently approve applicability and evidence requirements, then account for each applicable control through an exact approved audit or eligible gap-treatment route.
Screen orientation
compliance_control:read is constrained by site and clearance. Register creation/revision/submission, register approval, coverage scheduling/submission and coverage review use compliance_control:register, :approve, :schedule and :review. Applicable process owners and gap-treatment owners must be active, scoped, cleared QUALITY_ENGINEER users. Register approval excludes its version author/submitter. Coverage review excludes its version author/submitter and the approver of the cycle's pinned register version; a visible QA button cannot bypass this independence.
Four summary cards show registers, ACTIVE registers, coverage cycles and frameworks pending QA. New register and coverage-cycle editors appear above the searchable framework list. Cards distinguish current and active register versions, with nested control maps, coverage entries and immutable histories. Submission/decision forms open below the list.
Field reference
The entries below describe the current screen controls and read-only values. They do not relax server-side validation, site scope, classification handling or required independence in a governed decision.
| Field or value | Control | Required or shown when | How to use or read it | Result |
|---|---|---|---|---|
| Search register / Filter register by status / Sort register | Search and two selects | Optional view controls. | Search framework number, title, issuer, edition, source reference, site or status. Filter framework status and sort by creation time or identity. Pending QA counts framework review states, not every pending coverage cycle. | Changes the visible subset only; summary cards are unfiltered. |
| Site / Authority type / Classification | Three selects | Required when creating the framework; retained on later revisions. | Choose STANDARD, CUSTOMER, CONTRACT, REGULATORY or INTERNAL and an authorized site/handling classification. The register records configured obligations, not hard-coded legal or standard clauses. | Defines the immutable framework identity and access scope. |
| Issuer / Register title / Edition / contract change / Source reference | Four text controls | Required at creation; issuer at least 2 characters, title at least 5, edition at least 1 and source at least 3. | Identify the issuing body, obligation set, exact edition/change and controlled source. These identity fields are not offered in the revision editor. | Anchors the configured controls to the declared authority version. |
| Effective from / Effective to (optional) | Two dates | Start required; optional end on/after start. | Declare the register-version validity interval. These dates do not schedule downstream work or enforce a retention policy by themselves. | Retains the effective period with the version. |
| Scope / Applicability basis | Two multiline text controls | Each required; at least 20 characters. | Explain the organisational/process boundaries and why this obligation set applies. | Provides the version-wide basis for QA review. |
| Control key / Clause / obligation reference / Title | Repeatable text controls | 1–300 controls; unique uppercase keys of letters, digits, underscores or hyphens; title at least 5 characters. | Map each actual clause or obligation to a stable control key. Add Control/Remove edits draft rows; check generated keys after removals. Do not invent clauses or treat the form as legal interpretation. | Builds the obligation-to-control map. |
| Applicability / Applicability rationale / Process area / Process owner | Select, two texts and named-user select | Rationale at least 20 characters and process area at least 3; owner required only for APPLICABLE. | NOT_APPLICABLE clears/disables the owner and omits it from submission, but still requires the rationale and other control fields. Choose an eligible Quality Engineer for applicable controls. | Separates owned controls from justified exclusions. |
| Configured control / workflow / Report reference / Test reference | Three text controls | Each required; at least 3 characters. | Cite the configured workflow, report and test that substantiate the control. These references document the mapping; they do not configure permissions or execute tests. | Retains the control implementation references. |
| Control description / Required evidence / Retention months / Segregation / permission requirement | Two texts, integer and text | Descriptions/evidence at least 20 characters; retention 1–1200 months; segregation at least 10 characters. | Describe the actual control, expected evidence, retention requirement and named-role separation. These are documented requirements, not automatic retention or access-policy changes. | Makes evidence and segregation expectations reviewable. |
| Risk / Gap status / Gap description | Two selects and conditional text | Risk LOW/MEDIUM/HIGH/CRITICAL; gap CONTROLLED/PARTIAL/GAP; description at least 20 characters for PARTIAL/GAP only. | Record residual gaps honestly. Changing gap status clears the description; CONTROLLED omits it from the payload. | Feeds the risk basis for later coverage prioritization. |
| Register-version evidence | Controlled evidence select | Required for initial and replacement register versions. | Select one CLEAN immutable version from an active same-site document within framework classification. | Pins the basis of the new draft version without overwriting approved history. |
| Period start / Period end | Two dates | Required for a new coverage cycle; end on/after start; disabled on revision. | A new cycle requires the exact active approved register version. The cycle retains that pinned version and period on revision; it does not automatically migrate when a newer register is approved. | Defines the fixed coverage-cycle context. |
| Risk threshold / Lookback months / Coverage methodology / Coverage conclusion | Two integers and two multiline texts | Threshold 1–100, lookback 1–120; methodology/conclusion at least 20 characters. | Explain prioritization and coverage. Scores at or above the threshold, or controls rated HIGH/CRITICAL, require approved audit coverage for QA approval. Recent-audit lookback uses planned end, from period start minus the declared months through period end. | Sets reproducible coverage rules and the declared conclusion. |
| Risk score / Coverage route / Coverage rationale | Integer, select and text per applicable control | Score 1–100 and rationale at least 20 characters; exactly one entry for every applicable control. | Choose SCHEDULED_AUDIT, RECENT_AUDIT or GAP_TREATMENT. Not-applicable controls are omitted. HIGH/CRITICAL or above-threshold controls cannot be approved with GAP_TREATMENT alone. | Accounts for every applicable control against its pinned register version. |
| Exact approved Flow 17 audit | Conditional select | Required for SCHEDULED_AUDIT or RECENT_AUDIT; exact same site and classification. | Both the exact programme version and current plan must be APPROVED. Scheduled coverage also needs an ACTIVE programme, a READY/FIELDWORK/REPORT_REVIEW/RESPONSE_PENDING/CLOSURE_PENDING audit and planned dates inside the cycle. Recent coverage needs CLOSED and planned end inside the lookback window. The server validates more than the dropdown filter. | Snapshots the existing approved audit as coverage; it does not create an audit. |
| Quality Engineer owner / Target date / Treatment reference | Conditional named-user select, date and text | Required only for GAP_TREATMENT; reference at least 3 characters; date inside the full cycle period. | Assign an eligible owner and real treatment reference. The UI supplies a minimum date, but the server also enforces period end. Audit routes omit all gap-treatment fields. | Records accountable treatment for a gap that is eligible for this coverage route. |
| Coverage-version evidence | Controlled evidence select | Required for each coverage version. | Select CLEAN same-site evidence supporting methodology, chosen audits and any gap treatments. | Pins the immutable risk-coverage package. |
| Submission note / Independent QA rationale / Decision / Decision evidence | Multiline text, conditional select and controlled evidence select | Note at least 10 characters and evidence required for submission and decision; APPROVE/REJECT required for QA. | The dynamic note label changes with the action. Select CLEAN same-site evidence even for submission. Register QA excludes version author/submitter; coverage QA also excludes the pinned register approver. | Submits or decides the selected register/coverage version while retaining attribution. |
Actions and effects
When to use: An authorized register author prepares and submits a complete mapping; independent QA decides.
What it does: Approval activates the version. Rejection retains it and enables New version; it does not silently alter the prior approved mapping.
When to use: The current version is rejected or the framework is ACTIVE.
What it does: Creates a replacement or amendment draft. The existing active version remains authoritative while an amendment is pending; approving the amendment supersedes that register version.
When to use: Start only from an ACTIVE framework and its exact active approved register, with every applicable control accounted for.
What it does: QA approval rejects high-risk gap-only coverage and requires an independent reviewer distinct from the register approver.
When to use: The current coverage version is rejected or the cycle is APPROVED.
What it does: Creates a revision against the original pinned approved or superseded register version and unchanged period; it never migrates the cycle to a newer register.
Lists and states
- Framework cards distinguish current draft/review version from active approved version and show applicability counts, control mapping, owners, evidence/retention expectations and version decisions. A pending amendment is not the active mapping.
- Coverage cards show the exact pinned register version, cycle periods, entries, priority, audit/treatment references, risk scores and immutable version decisions. Later framework amendments do not relabel or migrate an existing cycle.
Authority boundary
Compliance governance never creates or changes audits, NCRs, supplier actions, configuration, custody or external messages. Control, retention and segregation text does not enforce those policies automatically. Approved coverage is evidence of the configured review, not legal certification or audit execution. A coverage cycle stays pinned to its original register version; approval of a new register does not migrate existing cycles.