GRC Capability Model Details - Perform Component
Perform is where the design meets reality. This domain tests how controls are designed, implemented and operated, how risk is treated, how obligations are met, and how issues, incidents and reporting are handled.
Purpose
Perform executes the plan: design and operate controls, apply policies and procedures, treat risk, satisfy obligations, respond to issues and incidents, retain evidence and report performance upward.
Core elements
- Control design - each key risk or obligation gets a control objective, control type (preventive, detective, corrective; manual or automated), frequency, owner and evidence. Design for the risk, not for the auditor.
- Policies and procedures - policies state intent; procedures tell people what to do and must be usable at the point of work.
- Risk treatment - avoid, reduce, share or transfer, accept; acceptance only by someone with delegated authority and only when documented.
- Operate - controls performed, exceptions flagged, records retained, segregation of duties respected.
- Issues and incidents - identify, contain, escalate, find root cause, remediate, learn.
- Reporting - first-line reporting upward through dashboards, indicators, exception reports and obligation status.
Design vs operation
A well-designed control that is never performed is worthless, and tests of design differ from tests of operating effectiveness. Perform belongs to the first line: the business performs the controls while risk and compliance advise and challenge.
Worked example
New vendor onboarding. Reasoning: obligations from Learn (sanctions screening, anti-bribery due diligence, data-protection clauses) define the risks (sanctioned counterparty, bribery, data breach). Design controls - screening before contract signature, due-diligence questionnaire, approval gate, contract clauses. Operate them: the buyer completes the steps, procurement checks. Evidence: screening records retained. Monitor and report: an exception report listing vendors missing checks, with named owners and thresholds.
Traps
- Offering "we have a policy" as proof that a control operates.
- Treating risk acceptance as a default with no delegated authority.
- Automating a broken manual process instead of fixing the design.
- Reporting only lagging results with no leading indicators.
- Keeping no evidence, so operation cannot be demonstrated when tested.