Plan Governance, Risk, and Compliance

Passing an audit is a compliance activity: it shows adherence to the requirements assessed, and NIST states that its risk management guidance is not a compliance checklist (NIST, FISMA background^[1]). The NIST Cybersecurity Framework (CSF) 2.0^[2] arranges cybersecurity outcomes (results to achieve, not actions to perform) by Function, then category. Managing supplier risk is a risk management activity: the CSF expects the risks posed by a supplier to be understood, recorded, prioritized, assessed, responded to and monitored over the course of the relationship (outcome GV.SC-07: Govern Function, Cybersecurity Supply Chain Risk Management category, outcome 07), so a breach through a cloud supplier that nobody assessed is a risk management gap. Keeping direction current is a governance activity: policy for managing cybersecurity risks is reviewed and updated to reflect changes in technology (GV.PO-02: Govern Function, Policy category) (CSF 2.0, Appendix A^[2]), so a security team that hears about a new product launch only a week before it goes live points to a governance gap. GV.SC-07 and GV.PO-02 are both Govern Function outcomes because the CSF connects the three activities through that Function: governance supplies the frame in which risk decisions and compliance decisions are made (CSF 2.0, section 2^[2]).

Governance, risk and compliance (GRC) is the practice of planning these three activities together so that security decisions stay consistent across the organization.

Three activities, three questions

Activity	Question it answers	What it produces
Governance	Who sets direction, on what authority, and how are results overseen?	Strategy, policy, roles and decision rights
Risk management	What could stop the organization from meeting its objectives, and what will it do about it?	Prioritized risks and risk decisions
Compliance	Which requirements apply, and can the organization show that it meets them?	A list of obligations and evidence of meeting them

Why plan them together

When poorly coordinated, each activity can miss what the others know. Relying solely on an audit checklist covers only the requirements on that checklist: it does not set business direction, and it does not assess risks that no requirement mentions. A risk team without governance has no agreed risk appetite to judge against and no clear decision-maker. Risk appetite is the types and amount of risk an organization is willing to accept in pursuit of value (NIST glossary: risk appetite^[3]). A governing body without risk and compliance input sets priorities without knowing the exposure or the obligations. Planning the three as one program helps coordinate priorities, decision-makers and records of what has been decided.

One way to lose that benefit is to treat an audit checklist as the whole GRC program. The checklist answers the compliance question only.

The takeaway: GRC coordinates governance, risk management and compliance, and each part brings a different perspective.

This section separates governance and management work inside a GRC program.

The distinction

ISACA's COBIT, a framework for governing and managing enterprise information and technology described in the COBIT section below, draws the line clearly (ISACA, 3 Things COBIT Is^[4]). Governance evaluates stakeholder needs, conditions and options to agree on balanced enterprise objectives, and sets direction through prioritization and decision-making. Management plans, builds, runs and monitors activities in line with the direction the governing body has set. The two encompass different activities, require different organizational structures and serve different purposes.

A simple test follows: if an activity sets the organization's direction or risk appetite, it is governance; if it plans and carries out work within that direction, including operational risk decisions, it is management. Approving organization-wide security priorities is governance. Operating the firewall or the endpoint protection software that enforces an approved policy is management, even though the policy it enforces came from governance.

Leadership is accountable

The CSF states that organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical and continually improving (GV.RR-01), and that adequate resources are allocated in line with the risk strategy, roles, responsibilities and policies (GV.RR-03) (CSF 2.0, Appendix A^[2]). Security specialists advise leadership and carry out assigned work, but advice is not authority. When a technician discovers a vulnerability, the decision to accept the remaining exposure belongs to the designated decision-maker with authority over that risk; if the technician lacks that authority, the technician's part is to report the finding and escalate it. Leadership keeps the accountability: it sets the risk appetite (GV.RM-02) and assigns roles and authorities (GV.RR-02), including the risk owner who decides about a specific risk (NIST IR 8286, Table 2^[5]), described in the risk register section below.

How direction and information flow

The CSF describes three levels that communicate in both directions (CSF 2.0, section 5.1^[2]), and they map onto the split above: executives govern; managers and practitioners manage within that direction. Executives set priorities and objectives and communicate expectations about risk appetite, accountability and resources. Managers decide how to reach the risk targets, expressed in a Target Profile (the CSF's statement of desired outcomes, explained in the CSF section below) and tracked in an action plan. Practitioners implement and operate the technology and report back the information managers and executives need, such as key performance indicators and key risk indicators. The figure below, modeled on the CSF's Fig. 5, shows direction flowing down through the three levels and practitioners sharing their updates, insights and concerns back up with managers and executives (CSF 2.0, section 5.1^[2]).

The takeaway: governance decides and oversees, management executes, and accountability for organizational risk stays with leadership.

This section explains why GRC planning matters to the organization as a whole: it ties security work to what the organization is trying to achieve.

Start from the mission

The CSF's Organizational Context category starts from the mission. The organizational mission is understood and informs cybersecurity risk management (GV.OC-01), internal and external stakeholders' needs and expectations are understood (GV.OC-02), and the critical objectives, capabilities and services that external stakeholders depend on are understood and communicated (GV.OC-04) (CSF 2.0, Appendix A^[2]). Together with the organization's constraints, such as budget and staff, these considerations decide which security outcomes matter most and where limited resources should go.

That is why one technical weakness can carry very different business weight. A flaw on the server that runs a hospital's patient-records service threatens a critical service; the same flaw on an isolated test server may matter far less. The default severity label a security product attaches to a finding (for example "critical" on a scanner report) describes the weakness in general terms; that label alone does not establish the impact on services the organization depends on. Prioritizing work by those labels alone skips the business-impact question that GRC planning exists to answer.

Cybersecurity risk is enterprise risk

Enterprise risk management (ERM) is the practice of managing all of an organization's risks as one portfolio. The CSF expects cybersecurity risk management activities and outcomes to be included in ERM processes (GV.RM-03), and NIST notes that treating risks alongside other enterprise risks, such as financial, cybersecurity, reputational and privacy risks, yields a more integrated outcome (CSF 2.0, section 5.2^[2]). NIST IR 8286r1^[6] describes the mechanism: cybersecurity risk registers (records of prioritized risks, see the risk register section below) from lower levels of the enterprise are normalized and aggregated into an enterprise risk register, and prioritizing that register produces an enterprise risk profile, which senior decision makers use to choose which risks to address, allocate resources and assign responsibility. Despite the shared word, this enterprise risk profile is not a CSF Organizational Profile, which describes cybersecurity outcomes (CSF 2.0, section 3.1^[2]), covered in the CSF section below.

A list of technical flaws, however accurate, does not tell leadership how a cyber event would disrupt operations, revenue or customers. The CSF describes itself as helping organizations translate cybersecurity terminology into general risk management language that executives understand (CSF 2.0, section 5.2^[2]), so that cybersecurity can be weighed against the other demands on the same resources.

The takeaway: GRC matters because it ranks security work by business impact and puts cybersecurity into the same decision process as every other enterprise risk.

This section covers who has to be involved in GRC planning, inside and outside the organization, and why the security team cannot plan alone.

Inside the organization

The CSF names an audience well beyond security staff: executives, boards of directors, acquisition professionals, technology professionals, risk managers, lawyers, human resources specialists, and cybersecurity and risk management auditors (CSF 2.0, Audience^[2]). These groups can contribute complementary information. The table lists common participants; it is illustrative, not exhaustive.

Participant	What they bring to GRC planning
Business managers	Which services and processes are critical, and what a disruption would cost
Legal and compliance staff	Which laws, regulations and contracts apply
Human resources	How people are hired, trained and offboarded; the CSF includes cybersecurity in human resources practices (GV.RR-04)
Procurement (acquisition)	Which suppliers are being engaged, and on what contract terms
Technology teams	How systems actually work, and which controls are feasible

Limiting GRC planning to IT administrators, on the grounds that most controls involve technology, leaves out the people who know the obligations, the business dependencies, the workforce and the suppliers.

Across organizational boundaries: suppliers

A supplier's service can affect whether the organization meets its own objectives, so suppliers belong in the plan. The CSF's Cybersecurity Supply Chain Risk Management category (GV.SC) expects that suppliers are known and prioritized by criticality (GV.SC-04); that cybersecurity roles and responsibilities for suppliers, customers and partners are established, communicated and coordinated internally and externally (GV.SC-02); that requirements are written into contracts and other agreements with suppliers (GV.SC-05); and that the risks a supplier poses are understood, recorded, prioritized, assessed, responded to and monitored over the course of the relationship (GV.SC-07) (CSF 2.0, Appendix A^[2]). Buying a service does not make security expectations clear on its own; they have to be stated and coordinated across the boundary.

Outsourcing changes who operates the infrastructure, not who depends on it. A business-critical service run by a provider stays in risk planning, because its failure can disrupt the organization's own work.

The takeaway: GRC planning draws on every function that holds relevant knowledge, and it reaches past the organization's boundary to the suppliers it depends on.

This section defines compliance as a GRC activity and marks its limits: what it covers, and what it cannot tell you.

Compliance has two halves

Compliance means adhering to the requirements that apply to the organization and being able to demonstrate that adherence. Both halves matter: a control that exists but leaves no evidence cannot be shown to an auditor, a regulator or a customer.

Three sources of requirements

The CSF expects that legal, regulatory and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed (GV.OC-03), and that the organization's own policy for managing cybersecurity risks is established, communicated and enforced (GV.PO-01) (CSF 2.0, Appendix A^[2]). A complete list of obligations therefore draws on three sources:

1. Laws and regulations, which government imposes.
2. Contracts, such as a security commitment made to a customer or an industry standard the organization has agreed in a contract to follow.
3. Internal policies, which the organization imposes on itself.

A requirement does not drop out of compliance tracking because it appears in a contract rather than a statute; breaking it still breaks a commitment the organization made.

Compliance is not the same as adequate protection

An assessment checks adherence to a defined set of requirements, while adequate protection depends on the organization's actual risks and operating conditions. NIST makes the point about its own guidance under FISMA, the US Federal Information Security Modernization Act, which requires each federal agency to run an agency-wide information security program: its suite of risk management standards and guidelines is not a "FISMA compliance checklist", and compliance with applicable laws and regulations is described as a byproduct of implementing a robust, risk-based information security program (NIST, FISMA background^[1]). The order matters in NIST's federal risk-based program: compliance follows from implementing that program, whereas a checklist alone does not address risks outside its scope.

A passed assessment is therefore a statement about its own scope at the time it was performed. Threats that appear afterwards, and systems or risks the assessment never covered, still need evaluation. Treating the pass as a reason to stop evaluating new threats confuses meeting a defined list of requirements with being protected.

The takeaway: compliance covers law, contracts and internal policy, it needs evidence, and it is one of three GRC activities, never a substitute for managing risk.

This section explains how the NIST CSF 2.0 supports planning.

Outcomes, not a checklist

The CSF offers a taxonomy of high-level cybersecurity outcomes that any organization can use to understand, assess, prioritize and communicate its cybersecurity efforts, and it does not prescribe how those outcomes should be achieved (CSF 2.0, abstract^[2]). NIST answers the checklist question directly: the CSF provides outcomes to prioritize and address cybersecurity risks but does not specify actions for meeting them (NIST CSF FAQs^[7]). Each organization tailors its use of the CSF to its own risks and needs and selects suitable controls to reach each outcome. Reading the CSF Core as a mandatory product-configuration checklist misreads it.

Govern directs the other five Functions

The CSF Core groups outcomes into six Functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern covers how the organization's cybersecurity risk management strategy, expectations and policy are established, communicated and monitored, and NIST places it at the center of the CSF's circular figure of the six Functions because it informs how the organization implements the other five (CSF 2.0, section 2^[2]). Its six categories line up with the GRC planning tasks on this page:

Govern category	What it covers in GRC planning
Organizational Context (GV.OC)	Mission, stakeholders, dependencies, and legal, regulatory and contractual requirements
Risk Management Strategy (GV.RM)	Priorities, constraints, risk appetite and risk tolerance (the level of risk or degree of uncertainty that is acceptable, per the NIST glossary[8]), and the link to ERM
Roles, Responsibilities, and Authorities (GV.RR)	Who is accountable and who decides
Policy (GV.PO)	Policy that is established, communicated, enforced and reviewed
Oversight (GV.OV)	Results used to adjust the strategy
Cybersecurity Supply Chain Risk Management (GV.SC)	Supplier risks and responsibilities

Establishing risk policy is therefore a Govern outcome. Detect is about finding and analyzing possible attacks and compromises; the fact that compliance with a policy will later be monitored does not turn setting that policy into a Detect activity. Nor are the Functions a sequence completed once: NIST says they should be addressed concurrently, with Govern, Identify, Protect and Detect activities happening continuously and Respond and Recover ready at all times (CSF 2.0, section 2^[2]).

Profiles turn gaps into an action plan

A CSF Organizational Profile describes the organization's cybersecurity posture in terms of the Core's outcomes. A Current Profile specifies the outcomes the organization is currently achieving, or attempting to achieve; a Target Profile specifies the desired outcomes it has selected and prioritized (CSF 2.0, section 3.1^[2]). NIST suggests five steps for using them, which the figure below traces: scope the Profile, gather the information needed, create the Profile, analyze the gaps between the Current and Target Profiles and create a prioritized action plan (for example a risk register or a plan of action and milestones, both explained in later sections), then implement the plan and update the Profile, repeating the steps as often as needed.

A Target Profile describes where the organization wants to be, so it is never evidence that any protection is in place. The Current Profile records the outcomes the organization is achieving or attempting now, and to what extent; only evidence behind it shows what is actually achieved.

Tiers describe rigor, not severity

CSF Tiers characterize the rigor of an organization's cybersecurity risk governance and management practices on four levels: Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3) and Adaptive (Tier 4), a progression from informal, ad hoc responses to approaches that are agile, risk-informed and continuously improving (CSF 2.0, section 3.2^[2]). Tiers complement the organization's risk management methodology rather than replace it, and they describe the organization's practices as a whole. A Tier is therefore not a severity rating for a single vulnerability, and it does not list technical controls.

The takeaway: the CSF says which outcomes to aim for, Govern directs the effort, Profiles measure the gap, and Tiers describe how rigorous the risk practices are.

This section covers COBIT and when it fits better than the CSF.

COBIT^[9] is the professional association ISACA's framework for the governance and management of enterprise information and technology (I&T). Its scope is the whole enterprise: in COBIT's terms, enterprise I&T covers all the technology and information processing the enterprise uses to achieve its goals, which includes the IT department but is not limited to it (ISACA, 3 Things COBIT Is^[4]). The governance-versus-management split described earlier on this page comes from COBIT. The framework defines the components used to build a governance system, such as processes, organizational structures, policies and procedures, information flows, culture and behaviors, and skills, and it groups them into governance and management objectives.

ISACA is equally clear about what COBIT is not. It is not a technical framework for managing all technology, and it does not make IT decisions such as which architecture is best or how much IT should cost; it defines which decisions should be taken, how, and by whom (ISACA, 3 Things COBIT Is^[4]).

Need in the scenario	Better fit
Align technology activities with business objectives across the enterprise	COBIT
Organize and communicate cybersecurity outcomes, and compare current with target posture	NIST CSF
Check how one system is configured	Neither: COBIT is not a technical framework for managing all technology (ISACA, 3 Things COBIT Is[4]), and the CSF does not prescribe how outcomes are achieved

The two frameworks can work together: ISACA publishes guidance on implementing NIST's earlier CSF version 1.1 using COBIT 2019 (ISACA, COBIT resources^[9]).

The takeaway: COBIT governs enterprise information and technology as a whole, the CSF organizes cybersecurity outcomes, and neither one assesses a single system's configuration.

This section explains control mappings, the GRC planning record that shows how one body of guidance relates to another, and the limit on what a mapping can prove.

An organization rarely answers to a single source of requirements. A healthcare provider might organize its program around the CSF, select safeguards from the NIST SP 800-53 control catalog, and also owe obligations under a regulation and several customer contracts. A control mapping (also called a crosswalk or framework crosswalk) identifies the relationships between security outcomes, safeguards, standards and regulatory requirements, so the organization can see where one control serves several requirements and where a requirement still needs its own control or its own evidence.

NIST publishes mappings for the CSF as Informative References: mappings that indicate relationships between the Core and various standards, guidelines, regulations and other content, which help inform how an organization may achieve the Core's outcomes (CSF 2.0, section 4^[2]). Some are narrower than one CSF outcome (a single SP 800-53 control may be one of many references needed), while others are broader (a policy requirement may partially address many outcomes). NIST's National Online Informative References (OLIR) Program^[10] collects mappings between other organizations' documents and NIST documents in a searchable catalog.

A mapping states that two items are related. It does not implement either of them, and it does not show that the organization does anything at all. A published control mapping from a framework to a regulation is a planning aid; demonstrating compliance still requires evidence that each relevant control is implemented and working.

The takeaway: control mappings show which guidance relates to which requirement, which makes them a planning aid, never proof of compliance.

This section covers the record that holds a GRC program's risk decisions and the role that makes them.

The risk register

A risk register is a repository of risk information, including the data understood about risks over time (NIST glossary: risk register^[11]). NIST IR 8286^[5] quotes the typical contents: a description of the risk, the impact if it occurs, the probability of its occurrence, mitigation strategies, risk owners, and a ranking that identifies higher-priority risks. Its register template also has a risk response type field: the risk response (sometimes referred to as the risk treatment) for handling the identified risk (NIST IR 8286, Table 2^[5]). NIST IR 8286 names four response types for a negative cybersecurity risk: accept, transfer, mitigate and avoid; mitigating applies actions, such as security controls, that reduce the risk to an acceptable level (NIST IR 8286, Table 3^[5]). Those contents make the register useful for planning: it records risk scenarios that have been identified, analyzed and prioritized, so discussions about exposure and progress start from one shared record rather than from scattered recollections of past problems. Registers kept at lower levels roll up into the enterprise risk register described under Cybersecurity risk is enterprise risk above.

An asset inventory looks similar, because both are lists, but it answers a different question. The inventory lists what the organization has; the register describes what could go wrong, how likely and how harmful it would be, and what is being done about it. An inventory is a useful input to finding risks, but it cannot serve as the register.

The risk owner

NIST IR 8286 defines the risk owner as the designated party responsible and accountable for ensuring that the risk is maintained in accordance with enterprise requirements; the risk owner may work with a designated risk manager who manages and monitors the selected risk response (NIST IR 8286, Table 2^[5]). Each risk in the register is assigned a risk owner, who is accountable for selecting and assigning appropriate risk responses. Supporting roles, such as the analyst who gathers evidence, the administrator who operates a control or the coordinator who keeps the register entry up to date, help the owner; performing this supporting work does not by itself confer authority to accept the remaining exposure.

The takeaway: the register is the shared, prioritized record of risk scenarios, and each entry names a risk owner whose delegated authority, not their access to the record, decides about that risk.

This section covers the record that turns a known gap into tracked corrective work, and the point at which that work counts as finished.

A plan of action and milestones (POA&M) is a tool that identifies tasks that need to be accomplished, the resources required, the milestones for meeting the tasks, and scheduled completion dates for the milestones (NIST glossary: POA&M^[12]). In NIST's Risk Management Framework (RMF), the POA&M describes the actions planned to correct deficiencies found during control assessments, audits and continuous monitoring. The authorizing official (the senior official with the authority to formally assume responsibility for operating a system, and the only official who can accept its risk, per Appendix D of NIST SP 800-37r2) reviews it to agree with the planned remediation, and it is then used to monitor progress in completing the actions (NIST SP 800-37r2, Task A-6^[13]). In an RMF authorization, this authority makes the authorizing official the system's risk decision-maker, matching the risk register section's rule: whoever holds the authority decides, not whoever does the work (NIST IR 8286, Table 2^[5]). When mitigation, not acceptance of the risk, is the selected response, the planned actions are tracked in the POA&M, and once the deficiencies are mitigated, assessors reassess the controls to determine whether they are implemented correctly, operating as intended and producing the desired outcome (Task R-3 in NIST SP 800-37r2).

The figure below traces that life cycle: a finding is identified, a POA&M entry plans the correction, the work is carried out against its milestones, the corrected control is reassessed, and only then is the finding closed. The CSF lists a POA&M among the examples of an action plan built from the gaps between a Current and a Target Profile (CSF 2.0, section 3.1^[2]), so the same record serves both purposes.

Approving a POA&M records the intended work; in the figure it belongs to the second step, not the last. Closing a finding when its plan is approved erases the difference between a known, unresolved weakness and an implemented improvement, and showing that difference is the reason the POA&M exists.

The takeaway: a POA&M links a known gap to planned work, and the gap stays open until the correction is complete and confirmed.

This section covers the software that holds GRC records; it supports the frameworks described above and does not replace them.

A GRC tool is software that stores and links the records described on this page, such as risk register entries, risk details, assessment findings, POA&Ms and policy documents, so that risk and compliance status can be seen in one consolidated view instead of in scattered spreadsheets. NIST IR 8286 notes that many organizations maintain formal, automated applications that provide detailed tracking and reporting, giving a GRC product as the example while describing the register roll-up covered under Cybersecurity risk is enterprise risk above (NIST IR 8286, section 3.8^[5]). NIST SP 800-37r2 adds that many commercially available GRC tools can reduce or eliminate hard-copy documentation in authorization work (NIST SP 800-37r2, Task R-1^[13]), and NIST IR 8286C observes that automated risk management tools for reporting and dashboards can give ongoing insight to stakeholders from operations managers to senior leaders (NIST IR 8286C^[14]).

Frameworks and tools divide the work. A framework such as the CSF describes the outcomes and practices to aim for; a GRC tool helps people apply and monitor that guidance consistently across a large organization. A tool does not decide what the organization should achieve; it tracks progress toward what governance has decided.

The takeaway: GRC tools give one consolidated, trackable view of risk and compliance records; tracking a control does not itself prove that the control is implemented.

This section covers a data format that lets GRC tools exchange control information.

Traditional compliance documentation uses a document-based approach in word-processor files and spreadsheets, rather than common, machine-readable standards for control data. NIST's Open Security Controls Assessment Language (OSCAL)^[15] introduces open, machine-readable formats in XML, JSON and YAML (three common structured-data file formats) for control catalogs, baselines, system implementation details and assessment results, with traceability from assessment findings and POA&Ms back to the originating control. Because the data is structured, tools can exchange it and automate parts of assessment and compliance work.

OSCAL represents information about controls; it does not operate any control. An OSCAL document can describe a control requirement and record what an assessment found, but enforcing the control remains the job of the system that implements it.

The takeaway: OSCAL lets control and assessment records move between tools as data; describing a control does not itself prove that the control is implemented.

This section covers when governance direction must be revisited, because a GRC plan rests on assumptions that change.

The CSF expects that policy for managing cybersecurity risks is reviewed, updated, communicated and enforced to reflect changes in requirements, threats, technology and organizational mission (GV.PO-02). Its Oversight category expects that strategy outcomes are reviewed to inform and adjust strategy and direction (GV.OV-01), that the strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks (GV.OV-02), and that risk management performance is evaluated (GV.OV-03) (CSF 2.0, Appendix A^[2]). A Target Profile likewise considers anticipated changes such as new requirements, new technology adoption and threat intelligence trends (CSF 2.0, section 3.1^[2]).

Four kinds of change that trigger a review

The four change types named in GV.PO-02 make a practical checklist of review triggers; the examples are illustrative.

Change	Example	Why the plan must be revisited
Requirements	A new regulation or a new customer contract	New obligations may not be covered
Threats	A new attack technique against widely used software	Earlier risk ratings may be too low
Technology	Launch of a new cloud-hosted service	Existing policy may never have considered it
Mission	A merger or a new line of business	Priorities and critical services shift

A recent approval date is not evidence of fit. A policy approved last year shows when direction was set, under last year's assumptions; whether it fits a service introduced this month is a separate question that only a review can answer.

The takeaway: GRC is a cycle, and when requirements, threats, technology or the mission change, direction is reviewed against current conditions.