Governance, Risk, Compliance and Security Management

Introduction and Context

Web and application security is often presented as a technical discipline concerned with secure coding, vulnerability scanning and incident response. In professional environments, however, security is also a governance problem. An organisation may possess excellent security tools and highly skilled engineers yet remain exposed because responsibilities are unclear, risks are not prioritised, suppliers are poorly controlled, evidence is unavailable, or senior management receives misleading assurance.

Governance establishes direction, accountability and oversight. Risk management determines what may prevent the organisation from achieving its objectives and how those risks should be treated. Compliance translates legal, regulatory, contractual and internal obligations into demonstrable controls. Security management integrates these activities into the software and service life cycle.

This chapter examines how a security professional can develop policies, standards, metrics, risk registers and assurance plans aligned with OWASP SAMM and ASVS, NIST SSDF and CSF, ISO/IEC 27001 and PCI DSS. It also addresses privacy, legal duties, ethical testing, procurement, reporting and management decision-making.

Learning Objectives

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

• distinguish governance, risk, compliance and security management;
• map application-security activities to major industry frameworks;
• develop usable policies, standards, procedures and guidelines;
• identify, assess, treat and monitor application-security risks;
• construct a meaningful risk register and assurance plan;
• select metrics that support decisions rather than merely report activity;
• incorporate privacy, legal, ethical and contractual duties;
• evaluate security requirements in procurement and supplier management; and
• communicate security conditions and residual risk to technical and executive audiences.

1. Governance as a Security Capability

Governance is the system by which an organisation is directed, controlled and held accountable. It answers questions such as:

• What security outcomes are required?
• Who has authority to accept risk?
• How are competing business, usability and security objectives resolved?
• How does the board or executive team know whether controls are effective?

Governance is distinct from management. Governance sets expectations, approves strategy and oversees performance; management plans, implements and operates controls. The distinction is not absolute: in smaller organisations one person may perform both functions, but the responsibilities should still be recognised.

A sound governance structure normally includes a governing body or executive risk committee, a security leader, product and engineering owners, legal and privacy specialists, internal audit, procurement and operational teams. Effective governance is based on accountability rather than the assumption that “security belongs to IT”. Product owners are accountable for business outcomes, engineering leaders for delivery practices, data owners for information decisions, and security specialists for advice, challenge and control design.

Policies, Standards, Procedures and Guidelines

These documents should form a coherent hierarchy.

A policy that says “systems must be secure” is difficult to enforce. A standard should specify scope, requirement, owner, exception process and evidence. For example, an application-security standard might require threat modelling for high-risk changes, peer review of security-sensitive code, dependency analysis, authenticated testing before release and documented remediation of critical findings.

Policies should be approved by an appropriate authority, communicated to affected personnel, reviewed periodically and controlled through versioning. Exceptions should be time-limited, justified, assigned to an accountable owner and accompanied by compensating controls where feasible.

2. Risk Management for Applications

Risk is commonly understood as the effect of uncertainty on objectives. In application security, a risk may arise when a threat can exploit a vulnerability, causing harm to confidentiality, integrity, availability, privacy, safety, finances or reputation.

A practical risk process consists of:

1. establishing context and risk criteria;
2. identifying assets, threats, vulnerabilities and affected stakeholders;
3. analysing likelihood and impact;
4. evaluating the result against risk appetite and tolerance;
5. selecting treatment;
6. recording ownership and due dates; and
7. monitoring residual risk and changing conditions.

Qualitative and Semi-Quantitative Assessment

Many organisations use a qualitative matrix. A simple inherent-risk score may be represented as:

Here, R is the risk score, L is likelihood and I is impact. If both variables use a 1–5 ordinal scale, the score ranges from 1 to 25. This is a prioritisation aid, not a probability estimate. The multiplication is meaningful only when the organisation has defined the scale and consistently applies it.

For example, an unauthorised access threat affecting a payment application may be assessed as likelihood 4 and impact 5:

The result indicates high priority under the organisation’s matrix. It does not mean that the event has an 80% chance of occurring, nor does it establish monetary loss.

A more economically oriented model may estimate annualised loss:

ALE is annualised loss expectancy, SLE is single-loss expectancy, and ARO is annual rate of occurrence. The model assumes that the loss estimate and occurrence rate are sufficiently credible and that repeated events can be approximated for planning. If a single incident is estimated at £100,000 and the expected frequency is 0.2 incidents per year, then ALE = £100,000 × 0.2 = £20,000 per year. Such estimates are uncertain and should support, not replace, expert judgement.

Risk Treatment

Risk can be treated by:

• avoiding the activity or architecture that creates the risk;
• reducing likelihood or impact through controls;
• transferring or sharing consequences through insurance or contracts; or
• accepting the residual risk through an authorised decision.

Acceptance must occur at the level authorised by policy. A developer should not silently accept a material production risk merely because a deadline is approaching. Risk acceptance should identify the risk, affected assets, rationale, expiry or review date, owner and required monitoring.

Risk Register

A useful register is concise enough to maintain but detailed enough to support decisions.

A risk statement should express cause, uncertain event and consequence. “Missing access control” is a condition; “A malicious user may access another tenant’s records because object-level authorisation is not enforced” is a decision-useful risk statement.

3. Aligning Major Frameworks

Frameworks are complementary rather than interchangeable. They provide vocabularies, practices and control expectations, but they do not remove the need for organisational judgement.

OWASP SAMM and ASVS

OWASP SAMM is a maturity model for improving software assurance across governance, design, implementation, verification and operations. It helps an organisation assess current capability, define a target state and plan incremental improvement.

OWASP ASVS is a verification standard. It provides testable requirements for areas such as architecture, authentication, session management, access control, validation, cryptography, error handling, data protection and API security. ASVS can be used to write security requirements, guide testing and define release evidence. Its verification levels should be selected according to application risk rather than treated as a universal checklist.

SAMM asks, in effect, “How capable and repeatable is our assurance programme?” ASVS asks, “What security properties should this application demonstrate, and how can they be verified?”

NIST SSDF and CSF

The NIST Secure Software Development Framework (SSDF) groups practices around preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. It is useful for integrating security into the software development life cycle and for communicating supplier expectations.

The NIST Cybersecurity Framework (CSF) provides outcome-oriented functions. The current core functions are Govern, Identify, Protect, Detect, Respond and Recover. The Govern function makes risk strategy, roles, policy, oversight and supply-chain expectations explicit. CSF outcomes can be used to structure an enterprise security profile and compare a current profile with a target profile.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS). Its risk-based approach requires defined scope, leadership, planning, support, operation, performance evaluation and improvement. The organisation selects controls appropriate to its risks and documents its treatment decisions, commonly through a Statement of Applicability.

Certification is evidence that an accredited certification process assessed the ISMS against the standard; it is not a guarantee that every application is secure or that no breach can occur. Internal audit, management review and corrective action remain important.

PCI DSS

PCI DSS applies to entities that store, process or transmit payment account data, and to systems that can affect the security of that environment. It contains requirements concerning network security, secure configurations, account management, access control, logging and monitoring, vulnerability management, secure development, testing and policy. Scope reduction through tokenisation, segmentation or outsourcing can be valuable, but scope must be validated rather than assumed. Contractual responsibility may be shared with a service provider while accountability for appropriate oversight remains with the merchant or service owner.

Framework Mapping

A mapping should identify outcomes and evidence, not merely place framework names in a spreadsheet.

Mappings should preserve each framework’s intent. A control may satisfy several objectives, but one checkbox should not be treated as proof of effectiveness.

4. Assurance and Evidence

Assurance is justified confidence that objectives and controls are designed appropriately and operate effectively. It is broader than penetration testing. Assurance may include architecture review, threat modelling, code review, automated testing, manual security testing, configuration review, supplier assurance, internal audit and management review.

An assurance plan should define:

• the system and boundaries under review;
• business and security objectives;
• applicable requirements, such as ASVS or PCI DSS;
• risk-based test scope and depth;
• independence and competence of reviewers;
• evidence to be collected;
• findings classification and remediation expectations;
• retest and closure criteria; and
• reporting recipients and escalation routes.

Evidence should be reliable, relevant, attributable, protected from unauthorised alteration and retained according to policy and law. Examples include approved threat models, pull-request records, test outputs, vulnerability tickets, deployment approvals, access reviews, logs and supplier attestations. A scan result without evidence that findings were triaged and resolved is weak assurance.

Security testing must be authorised. A written rules-of-engagement document should define targets, methods, time windows, prohibited actions, source addresses, emergency contacts, handling of personal data and stop conditions. Testing production systems without permission can constitute unlawful access even when the tester intends to help.

5. Metrics and Management Reporting

Metrics are useful only when linked to decisions. Common measures include:

• percentage of high-risk applications with current threat models;
• proportion of releases meeting required security gates;
• median time to remediate vulnerabilities by severity;
• percentage of critical dependencies within approved support periods;
• recurrence rate of previously identified control failures;
• percentage of privileged accounts reviewed on schedule;
• number and age of open risk acceptances; and
• supplier assessment completion and exception rates.

A count of vulnerabilities may increase because detection improved; therefore, counts alone can mislead. Metrics should include definitions, scope, sampling method, data source, frequency, owner, target and limitations. Leading indicators measure preventive activity, while lagging indicators measure outcomes such as incidents or losses. Both are needed.

A management dashboard should distinguish:

• status: what is currently true;
• trend: whether it is improving or deteriorating;
• exposure: what could happen and to whom;
• decision required: what authority or resource is needed; and
• confidence: how reliable the evidence is.

For example, “92% of critical findings closed within 30 days” is more useful when accompanied by “the remaining eight findings affect two internet-facing systems; one requires executive risk acceptance.”

6. Privacy, Legal and Ethical Duties

Application security and privacy overlap but are not identical. Security protects information and systems; privacy concerns the lawful, fair and transparent processing of personal data and the rights of individuals. Privacy-by-design activities include data minimisation, purpose limitation, retention controls, access transparency, appropriate protection and deletion processes.

A privacy impact assessment may be required where processing is likely to create high risk to individuals. Security teams should understand the data lifecycle: collection, use, sharing, storage, backup, analysis, archival and disposal. Test data should be synthetic or appropriately de-identified where possible. Production personal data copied into development environments creates avoidable exposure.

Legal duties vary by jurisdiction and sector. They may include data-protection law, breach notification, records obligations, intellectual-property restrictions, computer misuse law, employment law, accessibility requirements and contractual duties. Organisations should obtain competent legal advice rather than treating a framework as a substitute for legal interpretation.

Ethical testing requires necessity, proportionality, competence, confidentiality and respect for affected people. A tester should minimise disruption, avoid unnecessary collection of credentials or personal data, protect findings, disclose vulnerabilities responsibly and preserve evidence. A “proof of concept” should demonstrate risk without causing avoidable harm.

7. Procurement and Third-Party Risk

Security begins before software is acquired. Procurement should define security requirements proportionate to data sensitivity, connectivity, criticality and supplier dependence. Requirements may address:

• secure development practices and vulnerability disclosure;
• authentication, authorisation, encryption and key management;
• logging, monitoring and incident notification;
• security update and end-of-support commitments;
• penetration testing and independent assurance;
• subcontractor and hosting arrangements;
• data location, return and secure deletion;
• audit and evidence rights;
• business continuity and exit assistance; and
• liability, confidentiality and regulatory cooperation.

A supplier questionnaire is not sufficient by itself. Evidence may include an independent audit report, penetration-test summary, architecture documentation, secure-development attestations, vulnerability response records and contractually enforceable service levels. The buyer should assess whether the evidence covers the actual service, period and scope.

Cloud responsibility is usually shared. The provider may secure infrastructure while the customer remains responsible for identity configuration, data protection, application code, secrets and tenant settings. The exact division must be documented and tested.

8. Management Decision-Making and Escalation

Security decisions involve trade-offs. A mature decision process makes assumptions and uncertainty visible. A decision paper should state the business objective, options considered, security consequences, cost, delivery effect, legal or regulatory implications, residual risk and recommendation.

Escalation is required when risk exceeds tolerance, a control failure affects regulated data, remediation deadlines cannot be met, or evidence is materially unreliable. Escalation should be timely and factual. It should not exaggerate technical severity, conceal uncertainty or assign blame before facts are established.

A useful distinction is between a vulnerability, an incident and a risk acceptance. A vulnerability is a weakness; an incident is an event that compromises or threatens confidentiality, integrity or availability; risk acceptance is an authorised decision to tolerate exposure. A vulnerability may exist without an incident, and an incident may occur through a weakness that was not previously known.

9. Illustrative Case: FinPay Mobile Services

Background

FinPay is an illustrative payment-service provider operating a mobile wallet and merchant API. It uses an external cloud platform, several software suppliers and a continuous delivery model. The organisation wishes to demonstrate alignment with PCI DSS, ISO/IEC 27001, NIST SSDF and OWASP practices.

Problem

An internal review found that teams used different definitions of “critical vulnerability”. Threat models were inconsistent, supplier evidence was collected only during onboarding, and the board dashboard reported the number of scans rather than actual exposure. A penetration test also identified an object-level authorisation weakness that could allow one merchant to retrieve another merchant’s invoice.

Analysis

The weakness affected confidentiality and contractual trust. Likelihood was assessed as 4 and impact as 5 on FinPay’s approved 1–5 matrix, producing an inherent score of 20. The cause included a shared API component, insufficient authorisation requirements and tests that checked authentication but not tenant isolation. The risk owner was the product executive, not the testing team.

Approach and Solution

FinPay adopted ASVS requirements for API authorisation and data protection, used SAMM to assess capability maturity, and mapped SSDF practices to its delivery pipeline. It introduced a standard requiring threat modelling for payment and multi-tenant changes, negative authorisation tests in CI, independent pre-release testing for high-risk services and documented release evidence.

The immediate vulnerability was contained by disabling the affected endpoint, reviewing access logs and notifying the incident and privacy functions. Engineers implemented server-side tenant checks and added regression tests. A supplier contract was amended to require vulnerability notification, evidence of secure development and cooperation with investigations. The risk register was updated with residual risk, monitoring and a review date.

The dashboard was redesigned to show high-risk exposure, overdue remediation, exception age, coverage of threat modelling and evidence confidence. Management approved resources for identity and access-management improvements and accepted a narrowly defined residual risk for a legacy service until its replacement date.

Outcome

The organisation obtained clearer accountability, improved evidence and more meaningful executive reporting. It did not claim that framework alignment eliminated risk. Instead, it demonstrated a repeatable process for identifying, treating, monitoring and accepting risk.

Learning Points

1. Authentication is not the same as authorisation.
2. Framework mapping must lead to evidence and decisions.
3. Risk ownership belongs to the person accountable for the affected objective.
4. Supplier assurance must continue throughout the relationship.
5. Metrics should reveal exposure and required decisions, not just activity.

10. Challenges and Limitations

Frameworks can encourage compliance theatre when organisations optimise for completed checklists rather than reduced risk. Mappings may become excessively complex, especially when control statements from several frameworks are merged without preserving meaning. Qualitative scores create an appearance of precision, while economic estimates can be highly uncertain. Automated tools produce false positives, miss business-logic flaws and cannot replace architectural judgement.

Small organisations may lack specialist staff, independent assurance and formal governance bodies. Proportionality is therefore essential: a smaller scope and simpler evidence set may be appropriate, provided important risks are not ignored. Conversely, large organisations may suffer from fragmented ownership, duplicated controls and inconsistent standards.

Artificial intelligence introduces additional governance questions. AI-assisted coding can generate insecure or licence-sensitive code; AI systems may expose confidential prompts or training data; and automated security decisions may be difficult to explain. Organisations should define approved uses, data-handling restrictions, human review, model and dependency provenance, testing requirements and accountability. AI should augment, not replace, qualified security judgement.

Best-Practice Principles

• Start with business objectives, information sensitivity and harm scenarios.
• Make requirements testable and assign an accountable owner.
• Use frameworks as complementary lenses, not as substitutes for judgement.
• Integrate security into design, development, deployment and operation.
• Maintain a living risk register with explicit residual-risk decisions.
• Collect evidence that demonstrates effectiveness, not merely activity.
• Use metrics to trigger action and resource decisions.
• Authorise testing and protect test data and findings.
• Include security, privacy and exit requirements in procurement.
• Review controls after incidents, major changes and emerging threats.

Chapter Summary

Governance gives application security direction, authority and accountability. Risk management identifies threats to organisational objectives, evaluates likelihood and impact, selects treatment and monitors residual exposure. Policies establish intent; standards make expectations measurable; procedures describe execution; guidelines support context-sensitive practice; and records provide evidence.

OWASP SAMM supports capability and maturity improvement, while ASVS provides verifiable application-security requirements. NIST SSDF integrates security into software development, and NIST CSF structures enterprise outcomes through Govern, Identify, Protect, Detect, Respond and Recover. ISO/IEC 27001 provides a risk-based ISMS and continual-improvement model. PCI DSS supplies specific requirements for payment-account-data environments. These frameworks should be mapped carefully, with attention to scope, evidence and effectiveness.

Effective assurance combines threat modelling, secure design, code and dependency review, security testing, monitoring, audit and management review. Metrics must communicate exposure, trend, confidence and decisions required. Privacy, legal duties, ethical testing and supplier responsibilities are integral to security management. Ultimately, management must make explicit, informed and authorised decisions about investment, remediation, exceptions and residual risk.

Key Terms

Governance: Direction, oversight and accountability through which an organisation is controlled.

Risk: The effect of uncertainty on objectives.

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

Risk tolerance: The acceptable variation around a defined objective or risk level.

Inherent risk: Risk before considering the effect of controls.

Residual risk: Risk remaining after controls and treatments are applied.

Risk register: A maintained record of risks, causes, consequences, ratings, owners and treatments.

Risk acceptance: An authorised decision to retain a specified risk.

Policy: A mandatory statement of organisational intent and principles.

Standard: A compulsory, measurable requirement.

Assurance: Justified confidence that objectives and controls are appropriate and effective.

Evidence: Information demonstrating that a requirement or control exists and operates.

OWASP SAMM: A maturity model for software assurance capability.

OWASP ASVS: A standard of verifiable application-security requirements.

NIST SSDF: A framework of secure software development practices.

NIST CSF: An outcome-oriented cybersecurity risk-management framework.

ISMS: An information security management system.

PCI DSS: Security requirements for environments handling payment account data.

Residual-risk owner: The person accountable for managing or accepting remaining exposure.

Rules of engagement: Authorised boundaries and conditions for security testing.

Review Questions

Short Answer Questions

1. What is the difference between governance and management in information security?
2. Distinguish a policy, a standard and a procedure.
3. Why is a qualitative risk score not the same as a probability?
4. What is the main difference between OWASP SAMM and OWASP ASVS?
5. Identify two types of evidence that may support an assurance conclusion.

Long Answer Questions

1. Explain the complete application-security risk-management process, from context establishment to residual-risk monitoring.
2. Compare the contributions of OWASP SAMM, NIST SSDF, NIST CSF and ISO/IEC 27001.
3. Discuss how privacy and legal obligations should influence application-security design and testing.
4. Explain how an organisation should construct a risk-based assurance plan for a high-value web application.
5. Evaluate the advantages and limitations of using security metrics in executive reporting.

Analytical / Application Questions

1. A multi-tenant API authenticates users correctly but does not verify that an invoice belongs to the requesting tenant. Analyse the risk, propose treatments and identify evidence required for closure.
2. A supplier provides a current security certificate but refuses to provide information about vulnerability notification and subcontractors. What procurement and governance actions should be taken?
3. An organisation reports that 98% of scheduled vulnerability scans were completed, yet serious incidents are increasing. Critically evaluate the metric and design a more useful management dashboard.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes OWASP SAMM from OWASP ASVS?

A. SAMM assesses organisational software-security maturity, while ASVS provides verifiable application-security requirements.

B. SAMM is a payment-card regulation, while ASVS is an incident-response standard.

C. SAMM is a penetration-testing tool, while ASVS is a privacy law.

D. SAMM defines cryptographic algorithms, while ASVS certifies cloud providers.

Correct Answer: A. SAMM assesses organisational software-security maturity, while ASVS provides verifiable application-security requirements.

Question 2

A risk is rated likelihood 4 and impact 5 on a defined 1–5 qualitative matrix. What is its score?

A. 9

B. 16

C. 20

D. 25

Correct Answer: C. 20

Question 3

Which action is an example of risk acceptance?

A. Removing the system that creates the exposure

B. Implementing stronger authorisation controls

C. Buying insurance for possible losses

D. An authorised owner deciding to retain documented residual risk

Correct Answer: D. An authorised owner deciding to retain documented residual risk

Question 4

Which NIST CSF function focuses on strategy, roles, policy and oversight?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: A. Govern

Question 5

What is the primary purpose of a security standard?

A. To provide optional suggestions only

B. To define compulsory, measurable requirements

C. To replace all technical procedures

D. To record an incident after it occurs

Correct Answer: B. To define compulsory, measurable requirements

Question 6

Which statement about ISO/IEC 27001 certification is most accurate?

A. It guarantees that no application vulnerability exists.

B. It proves every supplier is secure.

C. It provides evidence that an ISMS was assessed against specified requirements.

D. It eliminates the need for internal audit.

Correct Answer: C. It provides evidence that an ISMS was assessed against specified requirements.

Question 7

Which practice is most appropriate during authorised penetration testing?

A. Copying all production personal data for convenience

B. Testing any internet host owned by the organisation without scope limits

C. Operating within documented rules of engagement and minimising harm

D. Publishing findings immediately to demonstrate transparency

Correct Answer: C. Operating within documented rules of engagement and minimising harm

Question 8

In the formula ALE = SLE × ARO, what does ARO represent?

A. Annual rate of occurrence

B. Authorised risk objective

C. Application recovery outcome

D. Annual review obligation

Correct Answer: A. Annual rate of occurrence

Question 9

Which metric is generally more decision-useful than the number of scans completed?

A. Number of engineers in the security team

B. Percentage of high-risk findings remediated within the approved period

C. Number of pages in the security policy

D. Total number of automated tools installed

Correct Answer: B. Percentage of high-risk findings remediated within the approved period

Question 10

Why should procurement address secure deletion and exit assistance?

A. To ensure the supplier can retain data indefinitely

B. To reduce the customer’s ability to change providers

C. To manage risks when services end and data must be returned or destroyed

D. To avoid defining security responsibilities in the contract

Correct Answer: C. To manage risks when services end and data must be returned or destroyed