Risk Management, Governance and Compliance

Introduction

Network security is not only a technical activity. Firewalls, encryption, authentication and monitoring are effective only when they support clearly defined business objectives, acceptable levels of risk and accountable decision-making. Risk management identifies what may harm an organisation, estimates the significance of that harm and selects proportionate controls. Governance establishes who has authority and responsibility. Compliance ensures that the organisation meets applicable laws, regulations, contracts and internal requirements.

For a network technician or security practitioner, these subjects have direct operational consequences. A technician may need to classify a server, apply a patching policy, preserve audit logs, report a suspected privacy breach or assess the security of a cloud provider. These decisions require more than product knowledge: they require an understanding of risk, policy, evidence and professional ethics.

This chapter presents practical foundations using recognised approaches, including the NIST Cybersecurity Framework, NIST Risk Management Framework, ISO/IEC 27001 concepts and the principles of privacy and data protection. The emphasis is on making defensible decisions rather than achieving a misleading claim of perfect security.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain risk, threat, vulnerability, likelihood, impact and control.
2. Perform a basic qualitative and semi-quantitative risk assessment.
3. Select controls using recognised security frameworks.
4. Explain the roles of governance, policies, standards, procedures and guidelines.
5. Develop useful security policies and performance metrics.
6. Discuss acceptable use, privacy, audits, third-party risk and regulatory obligations.
7. Apply ethical reasoning to common network-security decisions.
8. Recommend a practical risk-treatment plan for a small organisation.

1. The Foundations of Risk Management

1.1 Asset, threat, vulnerability and risk

An asset is something valuable to an organisation, such as information, hardware, software, services, reputation or human safety. A threat is a potential cause of harm. Threats may be accidental, environmental, technical or deliberate. Examples include phishing, ransomware, equipment failure, fire, insider misuse and supply-chain compromise.

A vulnerability is a weakness that can be exploited or triggered by a threat. Examples include unsupported software, excessive privileges, weak passwords, poor physical protection and inadequate backup testing. A vulnerability does not automatically create an incident; it creates exposure to a threat.

An impact is the consequence if an unwanted event occurs. Impact may involve confidentiality, integrity, availability, legal compliance, finances, safety or reputation. Risk is the possibility that a threat will exploit a vulnerability and produce an impact. Risk is therefore not the same as a vulnerability or an incident.

A useful conceptual relationship is:

Likelihood and impact may be expressed qualitatively—such as low, medium and high—or numerically. This relationship is a decision aid, not a universal law of probability. A numerical score is meaningful only when the organisation defines its scales consistently.

1.2 Inherent, residual and accepted risk

Inherent risk is the exposure before additional controls are applied. Residual risk is the exposure remaining after controls are implemented. No practical control eliminates all risk. Management must decide whether residual risk is acceptable, whether further treatment is justified or whether the activity should stop.

Risk treatment normally takes one or more of four forms:

• Avoid: stop the activity that creates unacceptable exposure.
• Reduce or mitigate: implement controls to lower likelihood or impact.
• Transfer or share: use insurance, contracts or outsourcing to distribute consequences; responsibility is not automatically eliminated.
• Accept: knowingly retain the risk within approved tolerance.

Acceptance must be informed and authorised. A technician should not silently accept a serious risk merely because no immediate budget exists.

1.3 Risk appetite and tolerance

Risk appetite is the broad amount and type of risk an organisation is willing to pursue or retain in achieving its objectives. Risk tolerance specifies acceptable variation for a particular process, asset or risk category. For example, an organisation may have low tolerance for unauthorised disclosure of health records but a higher tolerance for a short interruption to a public information website.

Risk decisions should consider business context. A control that is appropriate for a bank may be disproportionate for a small community organisation. Conversely, a small organisation may still have strict obligations when processing sensitive personal data.

2. A Basic Risk-Assessment Method

A practical assessment can follow these stages:

1. Establish scope, business objectives, assumptions and risk criteria.
2. Identify assets, owners, data flows and important dependencies.
3. Identify relevant threats and vulnerabilities.
4. Estimate likelihood and impact.
5. Prioritise risks.
6. Select and document treatments.
7. Assign owners and deadlines.
8. Monitor changes and reassess.

The assessment should involve asset owners and operational staff, not only security specialists. A network diagram, asset inventory, data classification scheme, incident history and supplier list provide useful evidence.

2.1 A semi-quantitative scoring method

One simple method assigns likelihood and impact values from 1 to 5:

Here, L is the likelihood score and I is the impact score. Both are dimensionless ordinal ratings, not monetary values or exact probabilities. If scores range from 1 to 5, the score ranges from 1 to 25. An organisation might classify 1–4 as low, 5–9 as moderate, 10–16 as high and 17–25 as very high, but these thresholds must be approved locally.

For example, suppose an unpatched internet-facing server has likelihood 4 and impact 5. Its score is:

This is very high under the stated scale. The result does not mean that an incident has an 80% probability. It indicates a priority for treatment compared with risks assessed using the same method.

A more financially oriented analysis may estimate annual loss. The single loss expectancy is:

The asset value is expressed in currency, while the exposure factor is the estimated proportion of value lost in one incident, from 0 to 1. If a service has an estimated value of $100,000 and a severe incident would affect 40% of that value, SLE = $100,000 × 0.40 = $40,000. If the estimated annual rate of occurrence is 0.2 incidents per year, then:

Thus, ALE = $40,000 × 0.2 = $8,000 per year. This estimate is uncertain and should not be treated as precise accounting. It is useful when comparing the cost of controls, provided assumptions are documented.

2.2 Risk registers

A risk register records assessment results and accountability. A useful entry includes the asset or process, risk statement, threat, vulnerability, existing controls, likelihood, impact, score, treatment, owner, due date, status and review date. A well-written risk statement identifies cause and consequence—for example: “Because remote-access accounts do not require multifactor authentication, an attacker using stolen credentials could access internal systems, causing unauthorised disclosure and service disruption.”

Risk registers should not become static spreadsheets. They should be reviewed after major technology changes, incidents, new suppliers, changes in law and significant changes in business operations.

3. Controls and Control Selection

A control is a measure that modifies risk. Controls may be:

• Administrative: policies, training, risk assessments and contracts.
• Technical: multifactor authentication, network segmentation, encryption, endpoint protection and logging.
• Physical: locks, barriers, secure areas, environmental controls and visitor management.

They may also be classified by purpose:

• Preventive controls aim to stop an event, such as access control.
• Detective controls identify events, such as intrusion alerts.
• Corrective controls restore or repair, such as incident response and backups.
• Deterrent controls discourage harmful behaviour, such as sanctions and warning banners.
• Compensating controls provide an alternative when the preferred control is impractical.

Controls should be selected according to risk, not popularity. Selection should consider effectiveness, cost, usability, legal requirements, availability, maintenance, accessibility and the possibility of creating new risks. A technically strong control that users routinely bypass may be less effective than a well-designed, usable control.

3.1 Defence in depth

Defence in depth uses multiple complementary layers. For example, protection of a remote-access service may include secure configuration, multifactor authentication, least privilege, network segmentation, logging, alerting, backup and tested incident procedures. Layers should not all depend on one mechanism; a single identity-system failure should not defeat every protection.

3.2 Recognised frameworks

The NIST Cybersecurity Framework (CSF) organises cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond and Recover. It is useful for communicating current and target states without prescribing one product.

The NIST Risk Management Framework (RMF) provides a lifecycle commonly expressed through Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor. It links system security decisions to organisational risk and authorisation.

ISO/IEC 27001 specifies requirements for an information security management system (ISMS). It emphasises organisational context, leadership, risk treatment, documented information, performance evaluation and continual improvement. ISO/IEC 27002 provides guidance on security controls. Certification, where pursued, is based on an audit of the defined ISMS scope and applicable requirements; it is not proof that no incidents can occur.

Other references may be relevant, including CIS Critical Security Controls, COBIT for governance and sector-specific standards. Frameworks should be mapped carefully. Similar words do not always represent identical requirements, and adopting a framework does not automatically establish legal compliance.

4. Governance and Policy Architecture

Governance is the system by which an organisation is directed, controlled and held accountable. Governance establishes objectives, authority, oversight and decision rights. Management plans and operates activities within that direction. A board or senior leadership may set risk appetite, while security managers and technical teams implement approved controls.

A practical policy hierarchy is:

Policies should identify purpose, scope, responsibilities, mandatory requirements, exceptions, enforcement, review frequency and related documents. They should be approved by an appropriate authority and communicated in language users can understand. A policy that cannot be implemented, monitored or enforced is a governance weakness.

4.1 Accountability and segregation of duties

Important responsibilities should be assigned explicitly. Common roles include asset owner, data owner, system administrator, risk owner, privacy officer, internal auditor and service provider. Segregation of duties reduces the possibility that one person can request, approve, implement and conceal a sensitive change. In a small organisation complete separation may be impossible, so compensating review and independent oversight become important.

5. Metrics, Monitoring and Audit

Metrics convert objectives into observable evidence. Useful security metrics are specific, consistently measured and connected to decisions. Examples include:

• percentage of critical assets with an identified owner;
• percentage of critical vulnerabilities remediated within the required time;
• multifactor-authentication coverage for privileged accounts;
• mean time to detect and mean time to contain incidents;
• percentage of successful backup-restoration tests;
• completion rate for access reviews and security training;
• number and age of unresolved high-risk findings.

A metric must define its numerator, denominator, scope, data source, reporting period and target. For example:

If 46 of 50 privileged accounts use MFA, coverage is (46 ÷ 50) × 100 = 92%. This metric does not show whether MFA is correctly configured or whether non-privileged accounts remain exposed; interpretation requires context.

Avoid vanity metrics such as the number of policies published or the number of alerts generated. More alerts may indicate better detection, worse security, or a noisy monitoring system. Balanced reporting combines leading indicators, such as patch compliance, with lagging indicators, such as confirmed incidents.

An audit is a systematic, independent and documented evaluation against defined criteria. Internal audits support improvement; external audits may support certification, contractual assurance or regulatory oversight. Audit evidence should be sufficient, reliable, relevant and traceable. Organisations should distinguish a finding, which is an observed condition, from a recommendation, which is a proposed response.

Audit integrity requires independence and evidence preservation. Staff must not alter logs, backdate records or conceal exceptions. Findings should be assigned owners and tracked to closure or formally accepted risk.

6. Acceptable Use, Privacy and Data Protection

An acceptable-use policy defines permitted and prohibited use of organisational systems. It should cover accounts, internet and email use, personal devices, removable media, software installation, monitoring, prohibited content, reporting duties and sanctions. It should be proportionate and communicated before enforcement. Monitoring should have a legitimate purpose, limited scope and appropriate transparency.

Privacy concerns the appropriate handling of information about identifiable people. Core principles found in many data-protection regimes include lawfulness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. Exact legal duties vary by jurisdiction, sector and role; staff must consult applicable law and the organisation’s privacy professionals.

Security and privacy overlap but are not identical. Encryption may protect confidentiality, but an organisation can still violate privacy by collecting unnecessary data or retaining it indefinitely. Privacy-by-design asks for privacy risks to be considered during system design rather than after deployment.

Important practical controls include data classification, access limitation, retention schedules, secure disposal, encryption, pseudonymisation where appropriate, breach procedures and records of processing. A privacy impact assessment may be appropriate when introducing high-risk processing, extensive monitoring, biometrics, profiling or a new technology involving personal data.

7. Third-Party and Supply-Chain Risk

Outsourcing a service does not outsource accountability. Cloud providers, managed-service companies, software vendors, contractors and hardware suppliers may access systems or sensitive information. Third-party assessment should consider data handled, access privileges, geographic location, subcontractors, resilience, incident history and exit arrangements.

Contracts should address security requirements, confidentiality, breach notification, access control, audit or assurance rights, vulnerability management, data location, retention and deletion, business continuity, subcontracting and return of data. Evidence may include independent audit reports, penetration-test summaries, security questionnaires and observed performance. Such evidence has limitations and should be matched to the risk.

A supplier should be monitored throughout its lifecycle: due diligence before selection, security requirements during onboarding, periodic review during operation and controlled termination. Concentration risk is also important: dependence on one provider or communication path may create a single point of failure.

8. Ethics and Regulatory Obligations

Security professionals hold privileged access and can cause substantial harm through misuse or negligence. Ethical practice includes confidentiality, competence, honesty, respect for privacy, proportionality and responsible disclosure. Authorisation is essential: scanning or testing a system without clear permission may be unlawful even if the intention is defensive.

When discovering a vulnerability, a professional should preserve evidence, avoid unnecessary access, notify the appropriate owner through an agreed channel and support remediation. Public disclosure should consider user safety, vendor response and the likelihood of exploitation. Employees should report conflicts of interest and refuse instructions to falsify audit evidence or bypass lawful safeguards.

Regulatory obligations differ across countries and industries. They may concern personal data, financial records, health information, critical infrastructure, electronic communications, breach notification, records retention or cybercrime. Compliance is not a checklist detached from risk. An organisation must identify which obligations apply, assign responsibility, retain evidence and seek qualified legal advice where interpretation is uncertain.

9. Illustrative Case: Riverside Technical College

Background

Riverside Technical College, a fictional institution, operates student information systems, online learning platforms, wireless networks and a small data centre. A review finds shared administrator accounts, inconsistent patching, unrestricted vendor remote access and backups that have never been restored in a test.

Problem

The college must reduce the likelihood and impact of ransomware while protecting student and staff information. Its budget is limited, and it cannot replace all legacy systems immediately.

Analysis

The assessment team identifies the student database and learning platform as high-value assets. The main risk statement is that stolen credentials or an unpatched public service could permit unauthorised access or ransomware, disrupting teaching and exposing personal data. Likelihood is rated 4 and impact 5, producing a score of 20 on the college’s 1–5 scale. A separate backup-restoration risk is rated likelihood 3 and impact 5, producing 15.

The team also identifies governance weaknesses: no named risk owner, unclear vendor obligations and no approved retention schedule. Technical weaknesses are therefore only part of the problem.

Approach and solution

The college approves the following treatment plan:

1. Require individual administrator accounts, multifactor authentication and quarterly privileged-access reviews.
2. Establish a critical-asset inventory and patch deadlines based on risk.
3. Segment student databases from general wireless and laboratory networks.
4. Restrict vendor access to approved time windows through a monitored gateway.
5. Maintain offline or otherwise protected backups and perform documented restoration tests.
6. Update acceptable-use, incident-response and data-retention policies.
7. Add security, breach notification and deletion requirements to vendor contracts.
8. Report MFA coverage, critical patch compliance, restoration-test success and overdue high risks to senior management.

Outcome

After three months, all privileged accounts use MFA, the most exposed systems are patched or isolated, and a restoration test identifies an outdated backup agent before an actual incident occurs. The college records remaining legacy-system risks for formal acceptance and schedules replacement funding. The outcome is not “zero risk”; it is improved visibility, reduced exposure and accountable decisions.

Learning points

The case demonstrates that risk treatment combines people, process and technology. A security tool cannot compensate for unidentified owners, weak contracts or untested recovery. It also demonstrates why metrics and evidence matter: management can judge progress only when controls are measurable.

10. Challenges, Limitations and Contemporary Developments

Risk scoring can create false precision. Different assessors may assign different ratings, and rare catastrophic events are difficult to estimate. Quantitative estimates depend on uncertain assumptions. Scenario analysis, expert review and sensitivity analysis can improve decisions, but none removes uncertainty.

Frameworks can also become compliance exercises. An organisation may possess policies and certificates while failing in daily practice. Control effectiveness should therefore be tested through technical validation, interviews, sampling, exercises and recovery tests.

Artificial intelligence creates additional governance questions. AI systems may process personal or confidential data, produce unreliable outputs, amplify bias or introduce new supply-chain dependencies. Organisations should define approved uses, prohibit entry of sensitive information into unauthorised services, validate outputs, retain accountability and assess providers. AI does not replace human risk ownership.

Modern environments also require attention to zero-trust principles, software supply-chain security, identity-centric controls, cloud shared-responsibility models and continuous monitoring. These are not substitutes for governance; they increase the need for accurate inventories, clear ownership and disciplined change management.

Best practice is therefore iterative: understand the organisation, prioritise important risks, implement proportionate controls, measure outcomes, learn from incidents and update decisions as technology and obligations change.

Chapter Summary

Risk management connects business objectives with security decisions. Assets, threats, vulnerabilities, likelihood and impact provide the vocabulary for assessing exposure. Risk may be treated by avoiding, reducing, transferring or accepting it, but acceptance should be informed and authorised. Qualitative scores and financial estimates can support prioritisation when their assumptions and limitations are documented.

Governance defines authority, accountability and oversight. Policies express mandatory direction, while standards, procedures, guidelines and records support implementation and evidence. Recognised frameworks such as the NIST CSF, NIST RMF and ISO/IEC 27001 help organisations structure activities, but no framework guarantees security or legal compliance.

Effective control selection combines administrative, technical and physical measures using defence in depth. Metrics should be well-defined and decision-relevant, and audits should rely on reliable evidence. Acceptable-use rules, privacy principles, third-party assurance, ethical conduct and regulatory awareness are integral to network security. The professional goal is not to claim zero risk, but to make transparent, proportionate and continuously improving risk decisions.

Key Terms

Asset: Something of value that requires protection.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited or triggered.

Risk: The possibility that a threat will cause harm through a vulnerability.

Impact: The consequence of an unwanted event.

Inherent risk: Risk before additional controls are applied.

Residual risk: Risk remaining after controls are applied.

Risk appetite: The broad level and type of risk an organisation is willing to retain or pursue.

Risk treatment: Action taken to avoid, reduce, transfer or accept risk.

Control: A measure that modifies risk.

Defence in depth: Use of multiple complementary protection layers.

Governance: Direction, oversight and accountability of an organisation.

Policy: Approved mandatory organisational direction.

Audit: Independent, documented evaluation against defined criteria.

Privacy: Appropriate protection and use of information about identifiable people.

Acceptable-use policy: Rules governing permitted use of organisational systems.

Risk register: A record of assessed risks, treatments, owners and status.

Residual risk owner: The person accountable for deciding how remaining risk is handled.

Segregation of duties: Dividing responsibilities to reduce error, fraud or abuse.

Compliance: Meeting applicable legal, regulatory, contractual and internal requirements.

Review Questions

Short Answer Questions

1. Distinguish between a threat, a vulnerability and a risk.
2. What is the difference between inherent risk and residual risk?
3. Name the four main forms of risk treatment.
4. Why should a security metric define its numerator and denominator?
5. State two reasons why third-party risk remains an organisational responsibility.

Long Answer Questions

1. Explain the stages of a basic risk assessment and describe the evidence that should support each stage.
2. Compare the purposes of the NIST Cybersecurity Framework, NIST Risk Management Framework and ISO/IEC 27001.
3. Explain how governance, policy, standards and procedures work together in a security programme.
4. Discuss the relationship between privacy and information security, including examples where one may be addressed without fully addressing the other.
5. Explain why audits and certifications do not prove that an organisation has zero security risk.

Analytical / Application Questions

1. A company has 40 privileged accounts, of which 34 use multifactor authentication. Calculate its MFA coverage and identify one limitation of this metric.
2. An internet-facing server has likelihood 4 and impact 5 on a 1–5 scale. Calculate its risk score, propose two treatments and explain what additional information is needed before accepting residual risk.
3. Design a short risk-treatment plan for a college that uses a cloud learning platform and allows vendors remote administrative access. Include technical controls, policy or contractual controls, ownership and at least three metrics.

Multiple Choice Questions with Answers

Question 1

Which statement best defines residual risk?

A. Risk that exists before any controls are applied

B. Risk remaining after controls are implemented

C. Risk transferred entirely to an insurer

D. Risk caused only by natural disasters

Correct Answer: B. Risk remaining after controls are implemented

Question 2

An organisation rates likelihood as 3 and impact as 4 using Risk Score = L × I. What is the score?

A. 7

B. 12

C. 16

D. 34

Correct Answer: B. 12

Question 3

Which is an example of a detective control?

A. Network intrusion alerting

B. A data-retention policy

C. A backup restoration procedure

D. A locked server-room door

Correct Answer: A. Network intrusion alerting

Question 4

Which NIST Cybersecurity Framework function focuses on identifying and managing cybersecurity responsibility and strategy?

A. Protect

B. Detect

C. Govern

D. Recover

Correct Answer: C. Govern

Question 5

What is the primary purpose of a risk register?

A. To replace all security policies

B. To record risks, treatments, owners and status

C. To guarantee that incidents cannot occur

D. To list only completed audit findings

Correct Answer: B. To record risks, treatments, owners and status

Question 6

If 46 of 50 privileged accounts use MFA, what is MFA coverage?

A. 46%

B. 50%

C. 92%

D. 96%

Correct Answer: C. 92%

Question 7

Which principle requires collecting only personal data necessary for a stated purpose?

A. Data minimisation

B. Segregation of duties

C. Non-repudiation

D. Availability

Correct Answer: A. Data minimisation

Question 8

Which statement about outsourcing security responsibility is correct?

A. Outsourcing always removes the organisation’s accountability

B. A contract makes technical controls unnecessary

C. The organisation remains accountable and should manage supplier risk

D. Third-party suppliers cannot create privacy risks

Correct Answer: C. The organisation remains accountable and should manage supplier risk

Question 9

Which document normally provides ordered steps for performing a task?

A. Policy

B. Procedure

C. Risk appetite statement

D. Audit opinion

Correct Answer: B. Procedure

Question 10

Why is unauthorised vulnerability scanning ethically and potentially legally problematic?

A. Scanning can never produce useful information

B. Authorisation is required before testing another system

C. Vulnerabilities are not relevant to risk management

D. Only physical controls require permission

Correct Answer: B. Authorisation is required before testing another system