Compliance is becoming harder to fake with a quarterly evidence scramble. That is the useful signal in Rapid7’s latest Experts on Experts discussion with Sergio Alonso, Rapid7’s Director of Trust, Risk, and Compliance.
The source is not a vulnerability disclosure and it is not a CVE security advisory. It is a practitioner conversation about how security teams are being forced to prove resilience more continuously as regulation, cloud change, and release velocity compress the old audit cycle.
What changed#
Rapid7’s main point is simple: compliance is moving away from a point-in-time exercise. Security teams can no longer treat readiness as something assembled shortly before an audit, then ignored until the next reporting window.
The pressure comes from several directions at once. Rapid7 names frameworks such as NIS2 and DORA as part of the regulatory backdrop. Both increase expectations around accountability and resilience. The source does not make a legal claim about how every organization must comply, and it does not map requirements line by line. The practical point is narrower: more organizations are being asked to show that controls work over time, not only that a policy existed when an auditor asked.
Cloud and faster release cycles make that harder. Infrastructure changes more often. Services move between teams. Controls may exist in one environment and drift in another. A clean report from last quarter tells less about the current state than it used to.
That is why Rapid7 frames compliance as something that needs to sit closer to security operations. The strongest version of the argument is not “automate compliance” as a slogan. It is that evidence should come from the systems where security work already happens: detection, asset visibility, access management, vulnerability management, change processes, and incident response.
Why this matters for security operations#
The gap Rapid7 calls out is familiar: security teams generate large volumes of operational data, but that data often does not become usable evidence for regulators, auditors, or leadership.
This is not only a tooling problem. It is a translation problem.
A vulnerability scanner, SIEM, cloud posture tool, ticket queue, or incident workflow may show useful facts. But an auditor or executive usually needs a different shape of evidence: who owns the control, what it covers, when it was last checked, what exceptions exist, whether remediation happened, and how the organization knows the answer is current.
If that bridge is manual, teams pay twice. First, they do the security work. Then they reconstruct proof after the fact. That creates delay, spreadsheet drift, and brittle reporting. It also encourages bad incentives: teams optimize for audit packets instead of control health.
Rapid7’s discussion points toward a better model: compliance as part of the operating workflow. That means the organization does not wait until reporting season to discover whether an asset inventory is wrong, whether cloud controls are inconsistently applied, or whether ownership is missing.
This is where a security advisory mindset is useful, even though the source is not about one specific advisory. In advisory handling, mature teams ask direct operational questions: are we affected, where, who owns remediation, what evidence proves the fix, and what remains exposed? Continuous compliance applies similar discipline to controls. The object is different, but the operating muscle is the same.
For teams tracking open source security, this matters as well. Dependencies, build systems, attestations, and package update practices often cross the boundary between engineering and compliance. If evidence lives only in a document repository, it will fall behind the actual system. Related reading: OpenSSF’s April signal: make security artifacts operational and Open Source Security Needs More Than Code.
What to check before acting on this#
The practical move is not to buy a “continuous compliance” label and declare the problem solved. Start with where proof breaks.
Check these areas first:
- Which controls still depend on manual screenshots, exports, or last-minute evidence collection.
- Whether each major control has a clear owner, not just a team alias.
- Whether operational tools can show current scope: assets, cloud accounts, users, services, repositories, and third-party systems.
- Whether exceptions are tracked with expiry dates and business owners.
- Whether remediation evidence is linked to the work that fixed the issue, such as tickets, pull requests, deployment records, or configuration changes.
- Whether leadership reports distinguish between policy existence and control performance.
That last point is important. Many organizations can prove they have a policy. Fewer can prove the policy is working across the environment today.
Automation can help when it reduces evidence drag and makes control status more current. It can also create false confidence if it only produces cleaner dashboards on top of incomplete data. A control that is mapped to the wrong asset set is still wrong, even if the report looks polished.
Security operations teams should also be careful with exploitability language. Compliance findings, CVE exposure, and exploit risk are related but not identical. A missing control may raise operational risk without proving active exploitation. A known CVE may require urgent patching even if it has no direct compliance mapping. Treat each as a signal, then connect them through asset context and business impact.
What not to overclaim#
Rapid7’s post promotes a video conversation, so the available source material is high-level. It supports the claim that compliance expectations are becoming more continuous and more tied to operational evidence. It does not prove that every organization is equally affected, that a specific product solves the problem, or that manual compliance work can be eliminated.
It also does not turn regulation into a single global story. NIS2, DORA, sector rules, customer requirements, and internal risk programs differ. Teams should not copy another company’s compliance operating model without checking their own obligations, geography, sector, and contracts.
The useful takeaway is narrower and stronger: if compliance evidence is detached from daily security work, it will age quickly. Cloud change, DevOps release patterns, and regulatory pressure all punish stale proof.
For security teams, the next step is operational checks, not rhetoric. Find the controls where evidence is slow, ownership is vague, and reporting depends on manual reconstruction. Those are the places where continuous compliance becomes real — or fails quietly.