Over the past year, many risk officers have been puzzled by a shift in regulatory expectations. Audit findings look similar, and controls haven't fundamentally changed, yet something feels different in how regulators and auditors respond to risk management programs.
Here's what's changed: regulators no longer want to hear about your risk register. They want evidence that you've reduced the likelihood and impact of incidents. The tolerance for performative risk management ended around late 2022, and 2023 marked the point where consequences started to appear.
These insights come from real conversations with practitioners navigating this shift. If you're managing a SOC 2 or ISO/IEC 27001 program, you've likely asked similar questions.
Do Regulators Really Care About My Risk Assessment Methodology, or Just Outcomes?
Both matter, but the focus has shifted significantly toward outcomes.
Your risk assessment methodology is important because ISO/IEC 27001 Clause 6.1.2 requires a documented process for identifying and analyzing information security risks. SOC 2 Trust Services Criteria CC3.2 requires identifying, analyzing, and responding to risks relevant to defined objectives. You can't skip the methodology.
However, regulators now expect you to prove that your methodology works. If ransomware is a critical risk you've identified for three years and you're still experiencing incidents, your risk assessment process isn't effective. It's just documentation.
Auditors now look for closed loops in your risk treatment plan. Did the risks identified in Q1 inform the controls implemented in Q2? Did those controls reduce the incident volume or severity in Q4? If your risk register remains unchanged while your incident log shows recurring patterns, there's an issue.
Your risk assessment can't be an annual exercise anymore. ISO/IEC 27001:2022 Clause 6.1.3(e) requires retaining documented information about the risk assessment process, but ongoing monitoring is also required under Clause 9.1. Connect these dots. Your risk assessment should inform quarterly or monthly reviews to check if treatments are reducing risk indicators.
How Do I Prove We're "Reducing Impact" When Incidents Still Happen?
You can't eliminate incidents, but you can show that your controls limited the damage and recovery time.
Start documenting containment metrics for every incident. When a phishing compromise occurs, how many accounts are affected? How long until detection and containment? What data was accessible during the compromise?
Compare those metrics over time. If a Q1 phishing incident affected 47 accounts and took 8 hours to contain, but a Q3 incident affected 3 accounts and took 45 minutes, you've got evidence that your security awareness training and detection controls are effective.
This is what auditors mean by "continuous improvement" under ISO/IEC 27001 Clause 10.2. It's not about adding more controls every year; it's about showing that existing controls are more effective at limiting damage.
For SOC 2, this ties directly to monitoring criteria. CC4.1 requires ongoing evaluations to verify that controls operate effectively. If you can't show that your controls reduce incident impact over time, you're not meeting that criterion.
What Happens If Our Risk Treatment Plan Doesn't Keep Up With New Threats?
You'll get findings, potentially major ones.
ISO/IEC 27001 Clause 6.1.3 requires assessing information security risks, and Clause 6.2 requires risk treatment. These aren't one-time activities. Clause 6.1.3(d) explicitly requires identifying risk owners.
If a new threat emerges relevant to your risk appetite and you don't update your risk treatment plan promptly, you're creating a gap between your documented ISMS and actual risk posture. That's a nonconformity.
Here's a practical test: when Log4Shell emerged in December 2021, how long did it take your organization to assess exposure, document the risk, and implement treatment? If you're still unsure, there's a process problem.
Your risk assessment process needs a trigger mechanism. Define what constitutes a material change in your threat landscape. New critical vulnerability in your stack? Acquisition of a new subsidiary? Regulatory change affecting your sector? Each should trigger a risk assessment review cycle, not wait for your annual assessment.
Are Regulators Actually Issuing More Penalties, or Does It Just Feel That Way?
The enforcement posture has shifted, even if the number of penalties hasn't dramatically increased yet.
What's changed is the threshold for acceptable risk management. Five years ago, having a risk register and an annual assessment often sufficed for compliance. Now, regulators expect your risk management process to be integrated into operational decision-making.
This shows up in audit findings as observations that escalate to nonconformities faster. An auditor might have flagged a stale risk register as an Opportunity for Improvement in 2021. In 2024, that same finding is more likely to be classified as a nonconformity against Clause 6.1.2, requiring corrective action.
Regulatory bodies are clear: they're frustrated with organizations treating risk management as a compliance checkbox rather than an operational discipline. Whether this frustration leads to more penalties depends on your jurisdiction and sector, but the direction is clear.
How Do I Get Leadership to Fund Risk Treatment When We Haven't Been Breached?
Reframe the conversation around regulatory exposure, not hypothetical incidents.
Your executive team might not care about the theoretical risk of a supply chain compromise, but they will care about the risk of a major nonconformity delaying certification renewal or triggering customer audit failures.
Build your business case around three points:
First, show specific control gaps flagged in recent assessments. Even minor findings indicate where your program is vulnerable to escalation.
Second, quantify the cost of audit delays. If your SOC 2 Type II report is late by two months due to remediating findings, what's the revenue impact from delayed customer contracts?
Third, connect risk treatment to operational efficiency. Implementing automated log aggregation isn't just a security control (ISO/IEC 27001 Annex A.8.15, Logging). It also enables your team to investigate incidents in minutes instead of days.
Where Should I Focus If I Can Only Fix One Thing This Quarter?
Fix your risk owner accountability structure.
Without clear risk owners with authority to implement treatments, everything else breaks down. Your risk register becomes a document that nobody acts on. Your risk treatment plan becomes aspirational. Auditors will flag this as a governance gap.
ISO/IEC 27001 Clause 6.1.3(d) requires identifying risk owners. That's not optional. But most organizations assign risk ownership to people without the budget or resources needed to treat the risk.
Meet with your leadership team and map every critical risk in your register to an executive with P&L authority over the affected system or process. That person owns the risk. They decide whether to accept, transfer, or treat it. They fund the treatment and answer for the outcomes.
Once you've got real ownership, the rest of your risk program starts functioning as it should.
Where to Go for More
If you're rebuilding your risk assessment process, start with ISO/IEC 27003 for ISMS implementation guidance and ISO/IEC 27004 for monitoring and measurement frameworks. For scenario-based risk assessment techniques that tie directly to business impact, NIST SP 800-30 provides practical methods that align with both SOC 2 and ISO/IEC 27001 requirements.
Your external auditor should be your first resource for understanding how enforcement trends affect your sector. They're seeing the same patterns across their client base and can tell you which findings are escalating from observations to nonconformities.
