Exciting news for AI governance! Rapid7 has achieved ISO/IEC 42001:2023 certification for our Artificial Intelligence Management System (AIMS). The certificate was issued by Schellman Compliance, LLC, an ANAB accredited certification body, following an independent audit of how we govern the AI systems we develop in our role as an AI provider.
What is ISO/IEC 42001?
ISO/IEC 42001 is the first international management system standard for artificial intelligence. Where ISO/IEC 27001 focuses on information security, ISO/IEC 42001 focuses on how an organization governs AI. What exactly does “governing AI” mean? Essentially, it means how AI risks and impacts are assessed, how data is managed, how systems are monitored once they’re in production, and how humans stay in the loop across the AI lifecycle.
This certification means an accredited third party has audited our AIMS and confirmed that it aligns to the standard. To note, this isn’t a one-time exercise, as the certification is maintained through annual surveillance audits. This means our AI governance program is held to the standard for as long as the certificate is active.
Why is ISO/IEC 42001 certification important?
AI is continually evolving how security teams work, and it’s also causing teams to reconsider the questions they ask their vendors. Where does the model come from? What data does it use? Who reviews its outputs? How do we maintain the integrity and quality of our AI products?
ISO/IEC 42001 certification gives customers independent evidence that Rapid7 has a management system in place to address those questions. It demonstrates that the in-scope AI systems are developed and operated under a structured program covering risk assessment, transparency, human oversight, and accountability.
It also supports customers in their own governance work. Many organizations are building AI risk into their third party risk programs and preparing for frameworks and regulations such as the NIST AI Risk Management Framework and the EU AI Act. A vendor's certified AIMS doesn't replace a customer's own due diligence, but it provides a credible, audited starting point.
As with cloud security, AI follows a shared responsibility model. Rapid7 is certified in the role of an AI provider, meaning we’re accountable for how we design, build, and operate these AI systems. Customers remain in control of how they use AI outputs within their own security operations.
Which AI systems are in scope?
The certification covers the AIMS supporting the following AI systems developed within Rapid7 products:
Agentic AI Workflow for MDR (Managed Detection and Response)
AI Dashboard Summary Card (Managed Detection and Response)
AI-Generated Risk Summaries (Exposure Command and Surface Command)
ICS Runtime Event Story (InsightCloudSec / Cloud Runtime)
Most of these are capabilities customers use directly within the product. Agentic AI Workflow for MDR supports Rapid7's own SOC analysts as they investigate and respond on behalf of MDR customers.
What's next?
ISO/IEC 42001 certification joins Rapid7's existing security and compliance program, which includes ISO/IEC 27001, SOC 2, FedRAMP, IRAP, ENS, BSI C5, as well as U.S. and international cybersecurity regulations. Each is independently assessed against its own defined scope, with details available in the Rapid7 Trust Center (reach out to your Account Executive for access).
As our AI capabilities grow, our AI governance program will grow with them. As such, we'll update this post if the scope of certification changes.
Customers can request a copy of the certificate through their Account Executive or Rapid7 representative. The certificate can also be independently verified in Schellman's public certificate directory.
On June 10, 2026, CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk." Strip away the regulatory language and it reads like a single operational fact: for a vulnerability that is actively exploited, publicly reachable, and grants an attacker full control, you now have three calendar days to remediate it — and you must run a forensic investigation in parallel to determine whether you've already been breached.
The 2026 Verizon Data Breach Investigations Report puts the industry's median full-remediation time at 43 days, adding that only 26% of Known Exploited Vulnerabilities were fully remediated in 2025, down from 38% the year before. That's a 43-day reality vs. a 3-day mandate; a gap you don't exactly just close by hiring more workers.
This blog aims to break down what BOD 26-04 actually requires, mapping each point to the Rapid7 capability that helps to make compliance operationally achievable for all.
What did CISA actually change?
BOD 26-04 supersedes and revokes two prior directives: BOD 19-02 (2019), which prioritized internet-facing vulnerabilities by static CVSS score, and BOD 22-01 (2021), which created the Known Exploited Vulnerabilities (KEV) Catalog but applied a 14-day patch deadline to every entry regardless of context.
Note that flat timeline: under BOD 22-01, an actively exploited bug on an air-gapped internal server carried the same 14-day urgency as one on a public-facing web server granting full admin control. Teams burned cycles patching low-risk systems to satisfy a checklist. BOD 26-04 replaces that with a dynamic model: prioritize what attackers are actually exploiting, and formally defer what they aren't.
The four variables to BOD 26-04
BOD 26-04 abandons CVSS as the sole trigger and evaluates every vulnerability against four binary variables, derived from the SSVC decision framework (CMU CERT/CC and CISA):
Asset Exposure: Is the asset reachable by untrusted entities over a public network?
KEV Status: Is the CVE on CISA's Known Exploited Vulnerabilities Catalog?
Exploit Automation: Can an attacker automate the full exploit chain, enabling mass exploitation?
Technical Impact: Does successful exploitation grant Total control (arbitrary code execution, full/admin privileges) or only Partial control (limited access, information exposure, denial of service)?
Asset exposure is the highest-leverage variable. If you remove an asset from public reach, you flip the exposure variable from Yes to No, and the required timeline relaxes accordingly. Rapid7 Labs data underscores why exposure dominates: half of the vulnerabilities actively exploited in the wild in Q1 2026 were zero-click, network-facing issues requiring no authentication, and by Q2 2026 nearly two-thirds required no user interaction at all. Attackers are going straight at exposed, unauthenticated surfaces.
CISA's new remediation tiers
The four variables combine into a graduated timeline (CISA BOD 26-04, Appendix A, Table 1). The tiers, simplified:
Tier
Timeline
Core criteria
1 (Critical)
3 days + forensic triage
On KEV and Total control
2 (High)
3 days (no triage)
Publicly exposed + Automatable + Total control, not yet on KEV
3 (Accelerated)
14 days
KEV-listed without Total control; or exposed + Partial control
4 (Standard)
60 days
Internal, automatable, Partial control
5 (Deferred)
Fix on next system upgrade
Internal + not KEV + not automatable + Partial control
Note that these timelines are dynamic. If a dormant vulnerability is added to the KEV, its clock can compress from 60 days to 3 overnight. Conversely, if you isolate an exposed asset, its clock relaxes. CISA explicitly counts isolation, mitigation, and uninstalling the vulnerable software as valid remediation; as such, a compensating control is a legitimate, compliant way to buy time for a safe patch.
The forensic triage mandate
This is the first of the requirements to have no precedent in earlier directives. For Tier 1 vulnerabilities (KEV + Total control), you must not only patch within three days, but run a concurrent forensic investigation to determine whether the asset is already compromised. Why? When an attacker exploits an exposed edge device, they establish persistence within hours; thus, patching three days later closes the door with the intruder already inside.
CISA's implementation guidance lays out a six-step, 72-hour protocol:
Phase
Window
What happens
1. Scoping
0–2 hrs
Identify in-scope devices; activate response team; open out-of-band comms
2. Preserve evidence
2–24 hrs
Capture volatile data (RAM, cache, registries) before any change
3. Patch & stabilize
2–24 hrs
Apply patches only after evidence is collected
4. Contain
6–24 hrs
Isolate infrastructure without tipping off the attacker
5. Triage analysis
24–48 hrs
Hunt IOCs; look for lateral movement and data staging
6. Escalation decision
48–72 hrs
Formal report; if compromised, report to CISA and pivot to full IR
Note the built-in tension between Step 2 and Step 3: patching reboots systems and overwrites the exact volatile memory that proves or disproves a compromise. You have to capture forensic evidence before you patch — at speed, across every affected endpoint. Doing that manually inside 72 hours is not always realistic.
Who CISA's BOD 26-04 applies to
BOD 26-04 is compulsory for all Federal Civilian Executive Branch agencies. It excludes national security systems and DoD/Intelligence Community systems.
It reaches the private sector indirectly, but firmly. Agencies must review contracts and push compliance onto supply-chain partners. For FedRAMP and cloud offerings, agencies stay responsible for their hosted systems' compliance, which forces CSPs handling federal data to adopt the same 3-day triage standard. If you're a contractor or CSP touching federal data, treat this as your standard too.
Mapping Rapid7 to the directive
Meeting a 3-day clock with mandatory forensics is impossible through manual process. Here's how the Rapid7 Command Platform maps to each requirement.
Variable 1 (Exposure) → Surface Command
You can't calculate a timeline if you don't know what's exposed. Surface Command combines Cyber Asset Attack Surface Management (CAASM) with External Attack Surface Management (EASM), correlating continuous external scanning against an internal asset inventory ingested from your existing tools. The result is a single view of your true external attack surface — including the shadow IT attackers can see but your team can't. When it flags an exposed asset carrying a KEV-listed CVE, you can sever exposure to flip Variable 1 and de-escalate the timeline while you test the patch.
Variables 2 & 3 (KEV + Automation) → InsightVM and Active Risk
InsightVM tracks the KEV Catalog natively in its Threat Feed Dashboard, continuously updating which assets carry actively targeted vulnerabilities. Its Active Risk score — a 0–1,000 scale — moves beyond static CVSS by ingesting exploit intelligence from Metasploit, ExploitDB, the CISA KEV list, and Rapid7 Labs research. That mirrors the directive's own logic: a CVSS 7.5 bug with a weaponized Metasploit module will outrank a CVSS 9.8 bug with no known exploit — exactly the prioritization BOD 26-04 demands.
The NVD scoring gap → Exposure Command AI CVSS
The National Vulnerability Database can't keep pace with disclosure volume, leaving many CVEs unscored — a blind spot when a zero-day drops and you need a timeline immediately. Exposure Command fills it with an AI model trained on historical NVD data. On its own the model returns the correct severity classification 76% of the time; combined with Active Risk, that rises to 87%, with any miss never more than one classification off. Exposure Command also enriches every asset with business criticality and threat telemetry, and its Remediation Hub surfaces the fixes that cut the most risk.
The forensic mandate → Velociraptor
Velociraptor — the open-source DFIR project Rapid7 acquired in April 2021 — is built for exactly the scale and speed the triage mandate requires. It maps directly to the protocol: agents capture volatile memory and running-process data across thousands of endpoints simultaneously (Step 2), and analysts use Velociraptor Query Language to hunt CISA-provided IOCs enterprise-wide in real time, returning only relevant artifacts instead of pulling full disk images over the network (Step 5). That lets you satisfy the evidentiary requirement without delaying the Step 3 patch.
From severity to dollars
BOD 26-04 shares a core idea with modern risk management: technical severity isn't business impact. A high CVSS score doesn't answer the board's question of "how likely is this to cost us?"
The FAIR framework closes that gap by expressing risk as expected annual loss: Annualized Loss Expectancy = Loss Event Frequency × Loss Magnitude
BOD 26-04 is effectively a mechanism for pinning down Loss Event Frequency: by isolating vulnerabilities that are exploited (KEV), reachable (exposure), and scalable (automation), it identifies the ones statistically most likely to become a loss event. Feed Active Risk into the frequency side and FAIR into the cost side, and you can brief leadership in the language of capital, not CVE IDs.
Authentication bypass enabling full takeover of remote-management endpoints
High-value management assets; total control; added to KEV August 2026
Checks shipped via content release; Velociraptor hunted endpoint artifacts to satisfy triage
What's next for federal agencies and contractors?
If you're an FCEB agency or a contractor or CSP handling federal data, the following three moves matter most:
Get exposure right. Everything downstream depends on knowing what's publicly reachable. Establish continuous external-plus-internal asset visibility now.
Wire KEV into prioritization, not a spreadsheet. The clock starts the moment CISA updates the catalog. Ingestion has to be automated and continuous.
Pre-stage forensics. Decide today how you'll capture volatile evidence across endpoints inside 72 hours. If that's a manual runbook, it will fail under a real Tier 1 event.
CISA BOD 26-04's bottom line
BOD 26-04 retires "patch everything" in favor of operational precision: remediate the actively exploited, exposed, high-impact vulnerabilities in 72 hours, prove whether you've already been breached, and defer the rest. Meeting it takes continuous asset discovery, live threat intelligence, context-aware prioritization, and forensics at scale — which is precisely the shape of the Rapid7 Platform. For federal agencies it's a mandate; for everyone else, it's the clearest blueprint yet for risk-based vulnerability management.
Sources: CISA BOD 26-04 and its implementation guidance; 2026 Verizon DBIR; Rapid7 2026 Global Threat Landscape Report and Q1/Q2 2026 threat data; Rapid7 product documentation for InsightVM, Active Risk, Surface Command, Exposure Command, and Velociraptor.
Issued nearly four years ago, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive 22-01 (BOD 22-01) has been adopted across both public and private sector organizations as a framework to ensure timely remediation of vulnerabilities being exploited by adversaries. By establishing a catalog of known exploited vulnerabilities (KEVs) and emphasizing a risk-based, prioritized approach, it provides a clear model for organizations to strengthen their cybersecurity posture and reduce exposure to real-world threats.
InsightGovCloud, Rapid7’s FedRAMP-authorized suite of security solutions, helps organizations implement BOD 22-01 by providing automated vulnerability scanning, real-time alerts for KEVs, and reporting aligned with regulatory requirements. Public and private sector teams can quickly identify at-risk assets, prioritize remediation efforts based on active exploitation, and maintain an auditable record of compliance. By leveraging our secure, cloud-based platform, organizations gain continuous visibility, streamlined vulnerability management, and the confidence that remediation aligns with federal cybersecurity standards.
How InsightGovCloud stacks up against key BOD 22-01 requirements
Requirement 1: Maintain continuous inventory and visibility
InsightVM, included in the suite, supports continuous and automated discovery of both external and internal assets through Discovery Connections, which allow organizations to continuously poll network sources like Active Directory, AWS, and Azure to enumerate connected hosts and launch scans.
For cloud environments, Rapid7 InsightCloudSec will continuously inventory the entire environment for the creation of new resources and automatically scan and assess those resources against compliance frameworks.
Rapid7 also maintains up-to-date inventory of CISA KEVs with an industry leading 90% coverage for both on-premise and cloud based host vulnerabilities.
Requirement 2: Remediate CISA KEV findings on a prioritized schedule
Continuous ingestion of CISA KEV catalog by Rapid7 ensures that detection and prioritization of KEV’s can be streamlined and native to one platform.
Automatically detect and triage assets with KEVs across cloud and hybrid environments.
Prioritize CISA KEV’s across your entire environment and establish remediation projects to quickly and collaboratively remediate KEVs.
Requirement 3: Establish policies and enforcement
Collaborative remediation and compliance goals automatically track and assign vulnerabilities to the right teams with organizational defined timelines and real time dashboards to measure progress.
Requirement 4: Automate reporting
Rapid7 has predefined exports in Cyberscope XML reporting format for seamless ingestion into reports for CyberScope submissions as per CyberScope Automated Data Feeds Submission Manual published by the U.S. Office of Management and Budget.
Built-in audit trail to demonstrate adherence with BOD 22-01.
Why agencies and contractors choose InsightGovCloud
Rapid7 InsightGovCloud is designed to support the rigorous requirements of state and local government agencies. The benefits are many, but among the top are its deployment into a FedRAMP Authorized environment – meeting federal security and compliance requirements at every level – its seamless integration into an existing security ecosystem, and its out-of-the-box alignment with CISA and CMMC security mandates.
Agencies and contractors enjoy a future-proof tool in that Rapid7 is continuously updating against the ever-growing KEV catalog, as well as unmatched visibility and control through leadership-friendly reporting. Get to know the platform better here.
The process that gates nearly every B2B deal is a self-assessment the sender distrusts and the receiver accepts. There is finally a better basis for trust between companies.
Parts 1 and 2 of this series looked at two pressures facing higher education security teams. First, the threat landscape: universities are dealing with more frequent attacks across complex, distributed environments, while campus-by-campus security can make it harder to share intelligence and coordinate response. Second, the compliance burden: overlapping requirements across FERPA, GLBA, HIPAA, and CMMC make it difficult to establish what data was affected, which reporting obligations apply, and how quickly the institution needs to act.
This final part is about what changes when a university system starts treating security as a shared capability rather than a collection of separate campus programs. Multi-campus institutions still need to preserve local autonomy, but they also need enough visibility across the wider organization to understand where risk sits, how an incident is spreading, and whether the same problem is appearing elsewhere.
That balance is especially relevant in higher education, where campuses, research environments, health services, and administrative teams often operate with very different technology needs and levels of independence.
Security architecture should reflect how universities actually operate
Most university systems are already federated organizations, with individual campuses managing their own leadership, budgets, users, and technology environments while a central office provides governance and oversight across the wider institution.
Security architecture can follow the same model. With multi-tenancy in the Rapid7 Command Platform, a central security team can maintain visibility across the university system while individual campuses continue to operate within their own environments. Campus-level data and access remain separated, while the central team can identify wider patterns, coordinate response, and distribute common workflows across the system.
A new attack pattern detected at one campus, for example, should not have to remain a local discovery. Shared visibility and coordinated workflows can help the central team determine whether the same activity is appearing elsewhere and make relevant response guidance available across the institution without exposing one campus's data to another.
As the university system grows, that model can expand with it. A system operating three campuses today can add new environments without redesigning the security architecture each time.
Shared visibility makes cross-campus response faster
A central view of the attack surface can reduce much of the manual work that happens when university teams need to answer a system-wide security question.
If a significant zero-day is disclosed, the central security team needs to know which campuses are running affected systems, which have already remediated the vulnerability, and where attention is still required. In a decentralized environment, gathering that information can mean emails, calls, spreadsheets, and separate conversations with each campus. A shared view of assets and vulnerabilities gives teams a faster way to establish where the exposure exists.
During an active incident, the same cross-campus visibility can help investigators work out whether suspicious activity first appeared at Campus C because the compromise began there, or because that is simply where it became visible. It also allows them to check whether the same indicators are present at Campus A or Campus B before each team starts investigating independently.
Universities also have large external attack surfaces that can be difficult to inventory centrally. Student portals, APIs, research servers, faculty websites, and other internet-facing assets may be created outside normal IT processes. Rapid7's Project Sonar continuously scans the public internet, helping organizations identify externally exposed services and assets that internal inventories may have missed.
Vulnerability prioritization needs more than a severity score
University security teams rarely have the capacity to remediate every vulnerability at once, so prioritization has to reflect how likely an exposure is to be used in a real attack.
Rapid7 combines vulnerability data with attacker intelligence, including insight from Metasploit, our open source penetration testing framework used by security professionals to test and validate real-world exploits, with more than 3,000 exploit modules.
That intelligence is combined with insight from AttackerKB, incident response engagements, honeypots, and other threat intelligence sources, giving teams additional context around whether an exploit exists, whether exploitation has been observed, and how difficult a vulnerability may be to use in practice.
For a university working through thousands of findings across multiple campuses, that context can help teams direct limited remediation capacity toward exposures with stronger evidence of attacker interest rather than relying on severity scores alone.
Incident response has to work across campus boundaries
The compliance requirements discussed in Part 2 put added pressure on investigation speed, particularly when legal or compliance teams need to establish whether regulated student, financial, health, or research data was accessed across more than one campus.
Rapid7's open source Velociraptor platform can collect forensic artifacts and run live investigations across thousands of endpoints simultaneously. In a multi-campus university, that could allow investigators to determine whether the same activity or data access occurred across several environments without conducting each investigation separately.
Automated response workflows can also be distributed across affected campus environments, allowing teams to isolate compromised systems, revoke credentials, or block indicators consistently rather than repeating the same response manually at each institution.
Campuses with smaller security teams benefit from that shared capability because the quality and speed of response are less dependent on how many people happen to be available locally when an incident occurs.
Consolidation can return time to stretched security teams
The operational case for a shared security model also comes down to the amount of work created by fragmentation. Separate campus tools mean separate licenses, integrations, training requirements, renewals, reporting processes, and vendor relationships, all of which consume time that understaffed security teams could be spending elsewhere.
The source material for this series includes an example of one organization recovering 96 hours per month by reducing manual work across disparate security tools. It also cites an average 74% improvement in mean time to detect where unified visibility and threat correlation were applied. For higher education teams working within tight regulatory reporting windows, the difference between finding an incident in hours rather than days can have a direct impact on how quickly the institution can assess scope and respond.
A system-wide agreement can also reduce the number of contracts, renewal cycles, and vendor relationships that central and campus teams need to manage, while allowing security capabilities to scale as the institution adds campuses, devices, and cloud services.
Building security around the university as a whole
Multi-campus universities will always have different technology needs across individual campuses, research environments, health services, and administrative functions. A connected security model does not require those environments to operate identically, but it does give central and local teams a better way to understand shared risk, coordinate investigations, and apply consistent response when an issue extends beyond a single campus.
Across this series, the same pattern has appeared from different angles. Threats move across organizational boundaries, regulated data rarely sits neatly within one campus, and the people responsible for protecting university systems are already working with limited time and resources. Bringing more of that security context together can help teams respond faster, share intelligence more effectively, and reduce the manual work created by disconnected tools and processes.
Rapid7 helps more than 11,000 organizations worldwide take command of their security. Learn more at rapid7.com/sled.
ON SECURITY By Susan Bradley It’s that time of the year again. No, not pumpkin spice — I’m talking about Cybersecurity Awareness Month. AI provided this definition: “October is recognized as Cybersecurity Awareness Month in the United States, led annually by CISA and the National Cybersecurity Alliance, with themes such as ‘Securing the Next 250’ […]
In Part 1 of this series, we looked at the security challenges created by fragmented, campus-by-campus environments. Higher education also faces a second pressure that makes that fragmentation harder to sustain: overlapping compliance obligations across FERPA, GLBA, HIPAA, and CMMC.
Each framework brings different requirements, reporting timelines, and consequences for failure. Managing them across one institution is already complex, but across a multi-campus university system with separate tools, staff, data stores, and governance practices, it becomes much harder to establish what happened, what data was involved, and which reporting requirements apply. With universities already facing an average of 4,388 cyberattacks per organization per week, according to the figures cited in Part 1, that regulatory complexity is becoming an operational security problem as much as a compliance one.
FERPA puts universities on a 24-hour clock
The Family Educational Rights and Privacy Act has governed the privacy of student education records since 1974, but the pressure on security teams becomes much more immediate when financial aid information is involved. If a breach compromises that data, institutions must notify the Department of Education’s Federal Student Aid office within 24 hours of discovery, leaving very little time to establish the scope of an incident while the response is still underway.
A ransomware attack discovered at 9 PM on a Friday makes the challenge easier to picture. By 9 PM Saturday, the institution may need to determine whether financial aid data was involved, understand which systems and students were affected, coordinate with legal teams, and prepare regulatory notification, all while investigators are still containing the incident and establishing what else the attackers accessed. In a multi-campus environment, that gets harder when financial aid data is spread across separate systems or when the initial discovery happens well after the compromise began.
GLBA brings financial-sector obligations into higher education
Universities may not look like traditional financial institutions, but their role in student lending and financial aid brings them within the scope of the Gramm-Leach-Bliley Act’s Safeguards Rule. Covered institutions are expected to maintain a written information security program addressing areas including risk assessment, access controls, encryption, multi-factor authentication, incident response, and vendor oversight.
Reporting requirements can add further pressure. If a security event affects 500 or more consumers, the draft notes that institutions must notify federal law enforcement immediately after discovering the breach. In a university environment, where shared financial aid systems may contain records belonging to thousands of students across multiple campuses, that threshold can be reached quickly.
The multi-campus structure matters here because financial aid data rarely follows neat organizational boundaries. Students transfer between campuses, shared services may centralize information, and one system may support several institutions. A breach that begins at one campus can therefore create obligations for the wider university system, making it important to understand the scope of the incident beyond the environment where it was first detected.
HIPAA reaches well beyond the university hospital
Protected health information can exist across a much wider university environment than the hospital alone. Student health centers, counseling services, physical therapy programs, and research projects involving human subjects may all create, receive, transmit, or maintain health data, sometimes through systems that have been procured and managed separately from central IT.
A mid-sized university with a health clinic, counseling center, physical therapy program, and clinical research lab, for example, could be handling significant volumes of PHI across several independently managed environments. If one of those systems is compromised, the security team needs to establish quickly whether health information was involved and how far the incident spread.
Under the requirements set out in the draft, breaches affecting 500 or more individuals must be reported to the Department of Health and Human Services within 60 days of discovery, while some incidents also trigger media notification requirements. For universities operating across several states or with online programs, the picture becomes more complicated again. Without a reliable view of where PHI resides across the institution, determining whether those reporting obligations have been triggered can itself become part of the incident response challenge.
CMMC raises the stakes for university research
CMMC creates a different kind of pressure for institutions conducting Department of Defense-funded research or handling Controlled Unclassified Information. Research computing environments are often among the most decentralized parts of a university: individual labs build their own systems, principal investigators make independent technology decisions, and networks can evolve over years without the consistency found in centrally managed administrative IT.
CMMC Level 2 requires organizations to demonstrate implementation of 110 security practices drawn from NIST 800-171. Meeting those requirements across a diverse research estate can be difficult without limiting the flexibility researchers need to conduct their work. For institutions that rely heavily on federal research funding, the consequences also extend beyond a conventional compliance penalty because failure to meet CMMC requirements can affect contract eligibility.
One incident can trigger several compliance obligations
The real operational difficulty appears when several of these frameworks apply to the same incident. A large research university may operate student financial aid systems, health services, a hospital, and DoD-funded research environments, creating the possibility that FERPA, GLBA, HIPAA, and CMMC obligations all come into play during one investigation.
Imagine ransomware is first detected on a shared administrative system. As the investigation develops, the compromised account is found to have accessed financial aid records, student health information, and a research environment containing CUI. The university now has to understand several categories of regulated data, determine which reporting thresholds have been met, coordinate with different agencies, and maintain the evidence required for each process while still responding to the attack.
That is difficult even with centralized visibility. When security data, incident records, and compliance evidence sit across different campus tools and teams, building a reliable picture of the incident takes longer and introduces more opportunities for information to be missed.
Preparing for compliance across a multi-campus system
Meeting overlapping compliance requirements depends on being able to answer a relatively small set of questions quickly: where regulated data lives, whether it was affected, how the attacker reached it, and what happened next. University systems need enough shared visibility across campuses to answer those questions without reconstructing the entire incident manually every time something happens.
That includes consistent data classification, centralized access to security and compliance evidence, and incident response processes that have already been tested against the reporting windows institutions may face. Automation can also help teams establish the scope and context of an incident more quickly, particularly where reporting deadlines are measured in hours rather than days.
The aim is to preserve the autonomy individual campuses and research environments require while giving the wider university system enough visibility and coordination to respond consistently when regulated data is involved. As the number of overlapping obligations grows, fragmented security becomes harder to separate from compliance risk.
In Part 3 of this series, we’ll look at how a consolidated security architecture can support that model across multiple campuses, from shared visibility and threat intelligence to more coordinated detection and response.
Rapid7 helps more than 11,000 organizations worldwide take command of their security. Learn more at rapid7.com/sled.
Compliance has become one of the biggest operational drains on modern security teams. CISOs are being asked to manage a growing sprawl of frameworks, prove control effectiveness more often, respond to more customer assurance requests, track risk across a growing web of third parties, and give executives and the board a clearer answer on whether cyber risk is actually going down.
Most of that pressure does not come from the frameworks themselves. It comes from the way compliance is still handled in many organizations, with security work happening in one set of tools and governance, risk, and compliance workflows managed somewhere else. Security teams detect exposures, investigate threats, validate risk, and drive remediation in active systems. Governance, Risk and Compliance (GRC) teams are often left managing controls, evidence, audits, third-party risk, and reporting in separate systems of record, which turns compliance into a constant reconciliation exercise rather than an extension of the security program.
That separation creates real drag. Skilled technical teams get pulled into repeated cycles of screenshots, exports, control validation, and spreadsheet updates, while CISOs are still left trying to answer the question that matters most: are our controls actually working right now?
Available today, Rapid7 Cyber GRC completely changes that model by connecting governance, risk, and compliance workflows to the security data and activity already happening across the environment. The result is a more connected way to reduce manual work, improve readiness, and turn security action into compliance proof.
Why compliance needs to move at the speed of security
For years, compliance work followed a familiar rhythm: prepare for the audit, gather evidence, prove the control, respond to findings, and start over when the next framework, customer review, or regulatory requirement arrives.
That rhythm works in conflict with how security teams operate today. Modern environments change continuously. Assets appear, cloud configurations drift, access permissions change, vulnerabilities emerge, vendors introduce risk, and remediation work is always in motion.
This leaves a widening gap between the state of the environment and the state of the evidence. A control that looked effective during the last audit may drift weeks later. A remediation effort may reduce risk, but the compliance record may not reflect it. A new exposure may change the risk tied to a control before the next review begins.
Boards and customers are asking for something more credible than periodic audit readiness. They want to understand whether security work is actually improving control health and reducing risk over time.
That is the shift from audit prep to continuous cyber assurance, built on better context and closer alignment between teams. As Bill Theissen, Managing Partner and VP of Consulting Services at Cyber Watch Systems, put it, “What excites me most about Rapid7 Cyber GRC is its ability to use existing security data, asset inventories, and API connectivity to produce more accurate, timely, and defensible risk reporting. Just as important, it helps bridge security engineering and GRC teams through a shared view of risk and a common language for communicating it.”
Cyber GRC is designed to support that shift by making governance, risk, and compliance part of how security teams prioritize, act, and prove progress. Compliance should not only document security activity after the fact - it should help show how that activity makes the business safer.
How Cyber GRC connects action to proof
Rapid7 Cyber GRC brings core GRC workflows into one place, including compliance program management, control monitoring, evidence collection, policy management, audit preparation, risk management, third-party risk management, exceptions, and reporting. Instead of managing those workflows in separate tools, teams can connect them to security context from the environment they are actively protecting.
Cyber GRC helps teams operationalize that model in a few practical ways:
Control monitoring helps teams see where requirements are being met and where gaps need attention.
Evidence workflows help teams collect, organize, and reuse proof across frameworks instead of rebuilding it for every audit.
Policy management helps link policies to controls, so teams can understand how documentation supports readiness.
Risk and issue workflows help teams assign ownership, track remediation, and prioritize work based on business and security context.
The value of that model is not just administrative efficiency. Security teams need confidence that controls are operating as intended, not simply that a control exists on paper. A policy may be in place without the control performing effectively. A remediation ticket may be closed without the underlying risk truly being reduced. Control testing and monitoring help close that gap by showing whether controls are functioning as expected, while issue and remediation workflows connect those findings to owners and next steps.
By connecting controls, evidence, risk, issues, policies, and remediation activity, Cyber GRC gives SecOps, IT, GRC, and compliance teams a shared view of where they stand and what needs to happen next.
Why third-party risk needs to be part of the same workflow
Third-party risk has become too significant to sit outside the rest of the security and compliance program. As organizations rely on more outside services, software, and vendors, they need a way to connect vendor risk to the same controls, evidence, remediation, and reporting workflows used internally. Verizon’s 2026 DBIR found that breaches involving third parties increased 60% from the previous year’s dataset and accounted for 48% of total breaches, which makes that connection harder to treat as optional.
Cyber GRC brings third-party risk management into the same operating picture by combining vendor oversight, control tracking, issue management, and evidence workflows in one place. That gives teams a more coherent way to assess external dependencies, understand where vendor risk affects control posture, and track action without creating yet another disconnected program.
Give leadership a better risk story
CISOs are under pressure to show progress in a way executives and boards can understand, and audit status alone does not tell the whole story.
Cyber GRC helps teams connect day-to-day security and compliance activity to higher-level reporting, including control health, readiness status, open risks, remediation progress, third-party dependencies, and evidence coverage. That gives leaders a clearer view of which gaps matter most, what is being done about them, and how security work is reducing risk.
IDC’s Phil Harris, Research Director for Governance, Risk, and Compliance (GRC) Solutions at IDC put this challenge into context: “Organizations face severe audit fatigue. The disconnect between compliance workflows and security operations creates significant operational drag, particularly when teams still rely on point-in-time spreadsheets and manual evidence collection.”
What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.
Why Rapid7
Security leaders have an opportunity to make compliance more connected, more useful, and closely aligned to the work already happening across their security program.
Rapid7 approaches Cyber GRC as part of a broader security program. What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.
That connection is at the core of what makes this solution different. Compliance proof is stronger when it is grounded in security context, not assembled after the fact from disconnected tools and static reports. With Rapid7 Cyber GRC, teams can move from documenting compliance activity to showing how security work is improving control health and reducing risk in real time.
"Tying GRC workflows directly into SecOps data is a strong approach because it allows CISOs to seamlessly align tangible security outcomes with compliance requirements. SecOps teams handle the heavy lifting in modern environments, and replacing manual, point-in-time audit preparation with continuous monitoring grounded in active security context, addresses a massive operational pain point for organizations," concluded IDC’s Phil Harris.
See how Rapid7 Cyber GRC can help your team turn security operations into continuous cyber assurance.
This webcast was originally aired on January 16, 2025. In this video, Kelli K. Tarala and CJ Cox discuss the challenges and strategies for improving governance, risk, and compliance (GRC) […]
Risk is real. To better understand cybersecurity risk, let’s compare cyber risks to risks in the natural world from hurricanes. We can learn lessons from hurricanes and unnamed storms in […]
Tom Smith // At Black Hills Information Security (BHIS), we deal with all manner of clients, public and private. Until a month or two ago, though, we’d never dealt with […]
Login
