1. Policy Management System
  2. Features
  3. Risks and controls
Feature · Risks and controls

Risks and controls

Connect unit risks to active controls and named owners.

OverviewActive controls
Policy Management System · Risks and controls

Active controls

Controls

New
Control codeDescriptionEffective fromRiskOwner
CC-941Active cnt-61913 OctRSK-9055
CC-855Active cnt-44513 OctRSK-6843
CC-810Active cnt-73409 OctRSK-6468
CC-403Active cnt-87605 OctRSK-4161
CC-242Active cnt-47222 OctRSK-2100
6 of 6 records
CC-941Controls · CNT-77232
DescriptionActive cnt-619
Effective from13 Oct
RiskRSK-9055
Example screen with sample data

What you can do

Give testing a clear subject

A risk belongs to a business unit and has an owner, likelihood, impact and named scale version. That version matters when reviewers compare scores across cycles: the number alone cannot tell them how the organization interpreted it. A control links to the risk, carries a code and description, has an effective date and names an owner. Those records provide the context for an assessment test.

The Control Owner defines the risk and keeps the control description current. The Assigned Tester selects the control being tested. Draft, active and retired status values let the team distinguish proposed measures from those in operation. The team should agree which control status is eligible for testing before the first assessment is released.

How the work is organized

  • Unit risk. Record the business unit and the scale version used for likelihood and impact.
  • Owned control. Give each control a code, description, effective date and accountable team member.
  • Test link. Point each test to its control so exceptions can be traced back to the relevant risk.

What to agree during setup

Define the likelihood and impact scales, then name their version. Agree who can update a risk assessment and who owns the control after it becomes active. Establish a code convention that stays stable across assessment periods. Decide how a retired control should appear in older test records and whether a replacement control gets a fresh code.

Start with the unit that will run the first assessment. Record one risk with a meaningful title and scale version, then link the control that mitigates it. Check the control’s effective date against the test period. If a control is still in draft, the tester should not treat it as operating evidence.

Check the handoff on an actual case

A business unit identifies a risk in its approval process. The Control Owner records the risk and scoring scale, then creates a control with a code, owner and effective date. The Assigned Tester uses that control in an assessment test and records the sample and exceptions. If the result fails, the finding points back to the same control, allowing the owner to see which measure needs repair.

When an Auditor reads the case later, the risk score, control status and test date should tell a coherent story. A later control change should not erase which control the original test examined.

What your team sees

  • Active controls — Measures available for current assessment planning and testing.
  • Failed tests — Failed results with the tested control code and evidence reference.
  • Open findings — Exceptions still tied to the control under review.

Follow the work through

What it keeps track of

Data model
Risks
Assessed risks with likelihood and impact on a named scale.
Controls
Controls that mitigate a risk.
Business units
Operating units that own risk and are assessed.
Team members
Named people with governance roles inside an organization.
Assessment tests
Individual control tests performed under an assessment.
Findings
Control failures and exceptions raised by testing.

Who uses it

Permissions
Control Owner
, Assigned Tester, Independent Assurance Reviewer, Auditor

Set up Policy Management System your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started