Back to GRC

Risk and Control Self-Assessment (RCSA): Process, Template and Examples

Risk and control self-assessment (RCSA) guide illustration: soft 3D tiles arranged in a 3x3 grid beside a sphere on a cream background

Short answer: A risk and control self-assessment (RCSA) is a structured workshop where the people who own a process identify its risks, rate them before controls (inherent risk), judge how well existing controls work, and agree the risk that remains (residual risk). Gaps become owned actions, and the results update your risk register and audit evidence.

Related guides:

Key takeaways

  • An RCSA is owner-led. The people who run a process assess its risks and controls, and the risk or compliance team facilitates and challenges.
  • The core output is a worksheet that moves each risk from inherent rating to control effectiveness to residual rating, with an action wherever residual risk sits above appetite.
  • An RCSA does not replace your enterprise risk assessment or an audit. It is a bottom-up input that keeps both honest.
  • Run it at least yearly per business area, and again after major changes such as a new product, a new vendor handling sensitive data or a significant incident.
  • Results should flow straight into the risk register and into the risk evidence you show for SOC 2, ISO 27001 and HIPAA.

What is a risk and control self-assessment (RCSA)?

An RCSA is a method, not a document: process owners sit down, usually in a facilitated workshop, and assess the risks in their own area and the controls meant to manage them.

The method comes from operational risk management in banking. The Basel Committee on Banking Supervision's Revisions to the principles for the sound management of operational risk (March 2021) lists, under the principle on identifying and assessing operational risk, tools that include self-assessments of both operational risks and controls. You do not need to be a bank to borrow it. For an SMB or HealthTech company, it gets engineering, support and product leads to own their risks instead of leaving everything to one compliance person.

Who owns what:

Role Responsibility in the RCSA
Process or risk owner (for example, Head of Engineering) Describes the process, identifies risks, rates them, attests to how controls really operate
Control owner Explains how the control works and what evidence exists
Risk or compliance lead Facilitates, provides scales and templates, challenges ratings, consolidates results
Leadership or risk committee Accepts residual risk above appetite or funds the fix

The owner's view is what you are capturing. The facilitator makes sure it is evidenced and consistent.

How is an RCSA different from a risk assessment or internal audit?

An RCSA is a bottom-up, owner-led check of specific processes, while a risk assessment is usually a top-down, organization-wide exercise and an internal audit is an independent test.

RCSA Organization-wide risk assessment Internal audit
Who performs it Process and control owners, facilitated Risk or security team with leadership Independent function or external party
Scope One process or business area at a time Whole organization or ISMS scope Selected controls or processes
Main question "What could go wrong here, and do our controls work?" "What are our biggest risks overall?" "Is the control designed and operating as claimed?"
Evidence standard Owner attestation plus sample evidence Analysis and judgment Testing and sampling
Typical output Worksheet, residual ratings, action plan Risk register, treatment plan Findings report

They work together. RCSA findings feed the organization-wide risk assessment, and internal audit can later test the controls owners rated as effective.

How do you run an RCSA, step by step?

Run an RCSA in seven steps: scope, prepare, identify risks, rate inherent risk, assess controls, rate residual risk, then act and report.

RCSA process flow diagram showing seven steps: scope, prepare, identify risks, rate inherent risk, assess controls, rate residual risk, act and report

  1. Scope the unit. Pick one process or business area, such as "customer data access" or "release management". Name the risk owner and the participants.
  2. Prepare the pack. Send the template, the rating scales, the current risk register entries for that area, recent incidents and any open audit findings. Ask control owners to bring evidence.
  3. Identify risks. In the workshop, walk the process end to end and ask what could go wrong at each step. Write each risk as cause, event and consequence.
  4. Rate inherent risk. Score likelihood and impact as if no controls existed. Keep this quick; it is a reference point.
  5. Assess controls. For each risk, list the controls that address it and rate design and operating effectiveness. Ask "how do you know?" and record the evidence.
  6. Rate residual risk. Re-score likelihood and impact with controls in place. Compare the result to your risk appetite.
  7. Act and report. For each residual risk above appetite, agree an action, an owner and a due date, or a formal acceptance. Consolidate results and update the risk register.

A workshop of 60-90 minutes per process area works well in our experience.

What goes in an RCSA template?

A usable RCSA template has one row per risk and columns that trace it from description through inherent rating, controls, residual rating and action.

Example RCSA worksheet card for a HealthTech access-control risk, showing inherent risk, controls, control effectiveness, residual risk and action, labelled as example values

Core columns: risk ID, process, risk description (cause, event, consequence), risk owner, inherent likelihood and impact, existing controls, control owner, control effectiveness, evidence reference, residual likelihood and impact, residual rating, within appetite (yes or no), action, action owner, due date.

Example worksheet (illustrative values only):

Field EXAMPLE row 1: HealthTech access control EXAMPLE row 2: Vendor data handling
Risk Former staff or contractors keep access to the production database holding patient data, leading to unauthorized disclosure A new analytics vendor receives patient data without a security review or agreement in place
Risk owner Head of Engineering (example) Head of Product (example)
Inherent rating High High
Controls SSO with offboarding tied to HR system; quarterly access review Vendor intake form; security review before purchase approval
Control effectiveness Partially effective: reviews happen, but service accounts are out of scope Ineffective: intake form is often skipped for low-cost tools
Evidence Last two access review exports Purchase records vs vendor inventory
Residual rating Medium High
Action Add service accounts to access review; owner: Platform Lead; due next quarter Block card purchases of data tools without approval; owner: Finance Lead

A rating without a written rationale is hard to defend to an auditor and impossible to compare next year.

How do you rate inherent risk, controls and residual risk?

Use the same likelihood and impact scales as your risk register, add a simple control effectiveness scale, and derive residual risk from both rather than guessing it.

Diagram showing how inherent risk combined with control effectiveness produces residual risk, compared against risk appetite

Likelihood and impact. A 1-5 scale for each, with plain-language definitions, is common. Define impact for the things you care about: patient or customer data exposure, service downtime, regulatory exposure and financial loss. Reuse the definitions you already have so RCSA scores line up with the register.

Control effectiveness. Keep it to three or four levels:

Rating Meaning
Effective Designed well, operating consistently, evidence available
Partially effective Designed well but with gaps in coverage or consistency
Ineffective Missing, not operating, or no evidence it operates
Not assessed New control or no owner yet; treat as ineffective until tested

Residual risk. Re-score with controls in place. As a sanity check, an "ineffective" control should not reduce the rating at all, and a "partially effective" one should rarely drop it by more than one level. Then compare residual risk to appetite: within appetite means monitor, above appetite means act or formally accept.

Which RCSA mistakes should you avoid?

The most common RCSA failure is optimism: owners rate their own controls as effective without evidence, so residual risk looks lower than it is.

  • No challenge. The facilitator accepts every rating. Fix: ask for one piece of evidence per "effective" control.
  • Generic risks. "Cyber attack" is not assessable. Write cause, event and consequence.
  • Scoring inherent risk forever. Spend most of the time on controls and residual risk, where decisions get made.
  • Actions without owners or dates. An unowned action is a wish. Record owner and due date in the session.
  • Spreadsheets that never reach the register. Separate files make the register drift. Consolidate every cycle.
  • Scales that differ from the register. If the RCSA uses different scales from your register, results cannot be compared. See our notes on internal control activities for how to describe controls consistently.

How often should you run an RCSA, and where do results go?

Run an RCSA for each key process area at least once a year, and trigger an extra one after significant change, then push the results into your risk register and framework risk processes.

Triggers for an off-cycle RCSA: a new product or major feature handling sensitive data, a new critical vendor, a significant incident or near miss, a reorganization that changes control owners, or a new framework in scope.

Where results go:

  • Risk register. Update inherent and residual ratings, owners and actions for each risk. New risks found in the workshop get added. Retired processes get closed.
  • SOC 2. In our experience, auditors want to see that you identify and assess risks on a regular cycle and act on them. Dated RCSA worksheets with owner sign-off and tracked actions are good evidence of that.
  • ISO 27001. RCSA output works well as an input to your ISMS risk assessment and risk treatment plan, particularly for naming risk owners and documenting how existing controls change the rating.
  • HIPAA. The Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI, and to implement security measures that reduce those risks to a reasonable and appropriate level. An RCSA on processes that touch ePHI can feed that risk analysis, but it is not a substitute for a full, documented analysis. Our HIPAA risk assessment guide covers the wider exercise.

How SecureSlate helps

SecureSlate gives you one place to run RCSA cycles and keep the results connected to the rest of your program:

  • Risk management: keep your risk register, inherent and residual ratings, owners and treatment actions in one place, so workshop output lands in the register instead of a side spreadsheet.
  • Multi-framework control mapping: link each risk to controls mapped across SOC 2, ISO 27001, HIPAA, HITRUST, NIST CSF and more, so one control assessment supports several frameworks.
  • Agentless read-only cloud integrations and access reviews: back up "effective" control ratings with evidence, such as completed access reviews.
  • Audit management: hand auditors dated, owned risk evidence when they ask how you assess risk.

Start a free SecureSlate trial and set up your first RCSA cycle.

FAQ

What does RCSA stand for?

RCSA stands for risk and control self-assessment. It is sometimes shortened to control self-assessment (CSA), although CSA can also refer to assessing controls without a separate risk rating step.

Who should facilitate an RCSA?

A risk, compliance or security lead who does not own the area being assessed, so they can challenge ratings and ask for evidence.

Is an RCSA the same as a HIPAA risk analysis?

No. An RCSA is a workshop method focused on specific processes and their controls. A HIPAA risk analysis must assess risks and vulnerabilities to ePHI across the organization. RCSA results on ePHI processes are a useful input to that analysis.

Can a small company run an RCSA without dedicated risk staff?

Yes. Start with a few process areas that handle sensitive data, use a one-page template and simple scales, and have a security or operations lead facilitate.

What is the difference between inherent and residual risk?

Inherent risk is the rating before any controls are considered. Residual risk is the rating after you account for how well existing controls actually work. The gap between them shows how much your controls are doing.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.

Need compliance without the complexity?

SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.

Find compliance gaps in 30 seconds

Filed under:

Author: SecureSlate Team

Keep reading

Oct 12, 2026 · GRC

Risk Transfer in Cybersecurity: Insurance, Contracts, Outsourcing and What Stays With You

Oct 11, 2026 · GRC

Quantitative vs Qualitative Risk Analysis: Which Should Your Team Use?

Oct 10, 2026 · GRC

MAS TRM Guidelines: What SaaS and HealthTech Vendors Selling to Singapore Financial Institutions Need to Know

View more posts
Jamie
Virtual Agent

Hi! I'm Jamie. Curious about your current compliance challenges and how automation might help your team?