7 Governance, Risk, and Compliance

Governance and security direction

Governance, risk management, and compliance connect cybersecurity decisions to an organization’s mission, responsibilities, and obligations. Governance sets direction and accountability; risk management helps leaders choose how to address uncertainty; and compliance helps demonstrate that applicable requirements are being met. Together, these activities support security decisions that are consistent, explainable, and reviewed over time.

The NIST Cybersecurity Framework (CSF) 2.0 makes governance explicit through its Govern function, alongside Identify, Protect, Detect, Respond, and Recover. Govern categories include organizational context, risk management strategy, roles and responsibilities, policy, oversight, and cybersecurity supply-chain risk management.

Policies, standards, and responsibilities

A Security policy is an organization’s formal statement of management intent and direction. Effective policies identify scope, responsibilities, and expectations; receive approval and communication; and are reviewed when organizational needs, threats, technology, or requirements change. They should be practical enough to enforce and align with the organization’s risk tolerance and applicable obligations.

Related documents have distinct purposes:

• Policy: States what is required and why. For example, “Sensitive data must be protected against unauthorized disclosure.”

• Standard: Defines mandatory, specific requirements that implement a policy. For example, “Administrative access must use multifactor authentication.”

• Procedure: Provides the steps for performing a task, such as requesting, approving, and removing an account.

• Guideline: Offers recommended practices or advice, usually with more flexibility than a standard.

Governance establishes who makes security decisions and who is accountable for them. Senior leaders approve strategy and risk tolerances; security and risk teams provide expertise and oversight; system and data owners make decisions for the resources they are responsible for; and users follow applicable requirements. Responsibility may be delegated, but accountability should remain clear.

Assessing and responding to risk

Risk is the possibility that a threat will exploit a vulnerability and cause harm. A Risk assessment considers threats, vulnerabilities or predisposing conditions, likelihood, and potential impact. Organizations may use qualitative ratings, quantitative estimates, or a combination. A simple low, medium, or high matrix helps prioritize risks but is not a precise measurement of loss.

Risk assessment is part of an ongoing process of assessing, responding to, and monitoring risk. A practical cycle is:

1. Establish context: Identify critical services, assets, stakeholders, legal or contractual obligations, and risk tolerance.

2. Assess risk: Identify relevant threats and weaknesses, estimate likelihood and impact, and prioritize the resulting risks.

3. Respond: Select an appropriate treatment and assign an owner.

4. Monitor and communicate: Track changes, treatment progress, and remaining risk; reassess when conditions change.

Common responses include:

• Mitigate: Reduce likelihood or impact with controls. Requiring multifactor authentication, for example, can reduce the risk of account compromise.

• Avoid: Stop or change the activity that creates the risk. An organization might discontinue a service that cannot be secured to an acceptable level.

• Transfer or share: Shift or share some financial or operational consequences, such as through insurance or contractual arrangements. This does not necessarily remove the organization’s responsibility or all risk.

• Accept: A designated decision-maker knowingly retains the risk, typically because it falls within approved risk tolerance or further treatment is not justified. Acceptance should be documented and revisited when circumstances change.

Inherent risk is the risk before relevant controls are considered; Residual risk is what remains after controls are applied. Controls reduce risk but rarely eliminate it. Acceptance belongs with an authorized business or risk owner, not automatically with the technical team that identifies the issue. Risk responses should align with organizational risk tolerance, and risk should be monitored over time.

Compliance and audits

Compliance means meeting applicable obligations. These may arise from laws and regulations, contracts, industry or government requirements, and internal policies. Organizations should determine which requirements apply to their activities, systems, locations, and data. A control framework can help organize security practices, but using one does not by itself prove compliance with every applicable obligation. Compliance also does not guarantee security: a compliant system can still have vulnerabilities or face risks that the requirements do not address.

An Audit examines evidence against defined criteria and can assess whether controls are appropriately designed, implemented, and operating as expected. Evidence may include policies, access records, configurations, interviews, and test results. Findings should be documented and followed by corrective action when needed. Control assessments determine whether controls are implemented correctly, operate as intended, and produce the required outcome.

Common audit perspectives include:

• Internal (first-party): The organization, or someone acting on its behalf, evaluates its own controls.

• External or independent: An outside party provides an independent assessment or assurance.

• Customer or supplier (second-party): One organization assesses another, often to evaluate contractual or supply-chain requirements.

An audit is not the same as a vulnerability scan or penetration test. Technical tests can provide useful evidence, but an audit also examines governance, documentation, processes, and whether controls meet stated criteria. Findings should have owners, deadlines, and remediation plans. Significant unresolved issues may require escalation or an explicit risk decision. A successful audit cannot guarantee that an organization cannot be breached.

Managing third-party security

Vendors, service providers, cloud providers, contractors, and other partners may access systems or data, or become part of a critical service. Their security weaknesses can therefore create risk for the organization. Third-party risk management should address the relationship throughout its lifecycle, not only during procurement.

A practical lifecycle includes:

1. Inventory and classify: Identify suppliers, their services and access, and the sensitivity or criticality of the data and systems involved.

2. Assess before engagement: Review security practices and relevant evidence in proportion to the supplier’s risk. Depending on the service, evidence may include control reports, certifications, security questionnaires, incident history, or an assessment.

3. Set contractual requirements: As appropriate, specify security responsibilities, permitted data use, access restrictions, incident notification, cooperation with investigations, subcontractor controls, audit or assurance rights, data return or deletion, and service continuity expectations.

4. Monitor during the relationship: Reassess high-risk suppliers, review service or ownership changes, track incidents and findings, and verify that agreed controls remain effective.

5. Manage exit: Revoke accounts and tokens, recover or securely delete data, transfer responsibilities, and confirm completion of termination obligations.

Supplier evidence should be evaluated for its scope, date, and relevance to the specific service. For example, a report covering one data center or product may not cover the vendor’s entire environment. A contract or insurance policy can help allocate obligations or costs, but does not automatically eliminate the customer’s operational, legal, or reputational exposure.