These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- GRC Audit Compliance
- Features
- Risks and controls
Risks and controls
Give each test a control and an accountable owner.
OverviewControls in Force×
GRC Audit Compliance · Risks and controls
New
Controls in Force
Controls
| Control code | Description | Risk | Owner | Effective from | Status | |
|---|---|---|---|---|---|---|
| CC-229 | Active cnt-949 | RSR-2375 | 18 Oct | Active | ||
| CC-710 | Active cnt-669 | RSR-9782 | 04 Oct | Active | ||
| CC-487 | Active cnt-645 | RSR-3050 | 23 Oct | Active | ||
| CC-329 | Active cnt-385 | RSR-6552 | 26 Oct | Active | ||
| CC-216 | Active cnt-527 | RSR-1247 | 18 Oct | Active |
6 of 6 records
CC-229Controls · CNT-15911
ActiveDescriptionActive cnt-949
RiskRSR-2375
Effective from18 Oct
What you can do
Give each test a control and an accountable owner
A risk record carries a title, likelihood, impact and scale version. It belongs to a business unit and has a named owner. A control then describes what addresses that risk, the date it became effective and the person who owns it. The active status helps a tester select controls that are in force for the assessment period. The parallel scored-risk family uses its own team-member and counterparty references; a test must follow its control into the matching family.
How the work is organized
- Source record. Start with the assessment, risk or finding that owns the work and follow its references before changing a status.
- Named responsibility. Use the linked owner or reviewer so the next action is accountable to a person in the organization.
- Recorded result. Retain the date, status, decision or evidence that explains why the work moved forward.
The Operations Overview helps the team see assessments, tests, decisions and failed operations in one context. Open the underlying record before acting, especially when two assessments have similar subjects. The record number, organization and period should identify the intended case. Decisions and retests should point back to the source they cover.
What to agree during setup
Agree the meaning of likelihood and impact, how a scale version changes and who can retire a control. Confirm whether a control effective date falls inside the assessment period. Give each control a useful code and description that a tester can recognize without guessing from the risk title. The team should rehearse these choices with a small, recognizable case before widening access. A named owner should check that a reviewer sees the right case and that a person outside the case cannot change it.
Check the handoff on an actual case
Take a risk involving privileged access in a business unit. The Control Owner records its likelihood and impact under the chosen scale version, then links an active control with an effective date. The Control Tester checks that the control was in force for the test date. A retired control remains part of earlier assessment history instead of being silently substituted. Walk the record from its first entry to the next person’s action. Check that dates, references and status tell the same story, and that evidence is available to the authorized reviewer. If the work is corrected, preserve the earlier result and the reason for the change. The team can then use the same handoff for a second case without relying on a side conversation.
What your team sees
- Controls in Force — Active controls with their risk and owner.
- Scored Risks by Unit — Risks grouped by business unit and recorded scale.
- Assessment Pipeline — Assessments that need a confirmed control scope.
Each view opens records with the fields needed for that decision. The person working the queue can compare the current status with the linked source, then open the record for its full history. A board or due-date list helps prioritize, while the recorded decision remains on the case.
Follow the work through
Follow assessment preparation, testing and findings, independent review and verified closure. Start with the process that owns the record on this page, then inspect the next handoff before releasing work to another role.
What it keeps track of
Data model- Risk scale register
- Risks scored on an explicit likelihood and impact scale version.
- Risks
- Scored risks that controls are designed to mitigate.
- Controls
- Controls mitigating a risk, owned and effective from a date.
- Scored risk controls
- Controls operating against scored risks, with owners and effective dates.
- Business units
- Units in scope for assessments and risk registers.
- Units counterparties
- Auditable business units and counterparties inside an organization.
- Control test staff
- Control owners, testers and independent assurance reviewers.
- Team members
- Named assurance staff who own assessments, controls and reviews.
Who uses it
Permissions- Control Owner
- , Assessment Owner, Control Tester.
- The Assessment Owner coordinates the case, while the Independent Reviewer makes the recorded assurance or retest decision when that stage applies.
- Admin
- Handles organizational access and receipt reconciliation.
Set up GRC Audit Compliance your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.