Governance, Risk and Compliance Standards

Why This Topic Matters
Governance, Risk and Compliance (GRC) is the framework that connects secure software development to the goals of the business. Security controls that are not tied to governance, not justified by risk, and not mapped to compliance obligations tend to be inconsistent, unfunded and unenforced. The CSSLP exam tests GRC heavily within Domain 1 (Secure Software Concepts) because a security professional who cannot explain why a control exists, who owns the decision, and which standard or regulation drives it cannot defend security requirements to management or auditors. In practice, GRC standards give you a common vocabulary, a repeatable method for prioritising work, and a defensible position when something goes wrong.

What GRC Is
Governance is the set of policies, roles, responsibilities and oversight mechanisms by which an organisation directs and controls security. It answers: Who decides? Who is accountable? How is performance measured? Governance is driven from the top (board and executive management) and flows down through policies, standards, procedures, baselines and guidelines.

Risk management is the process of identifying, analysing, evaluating, treating and monitoring risk so that it stays within the organisation's risk appetite and risk tolerance. Risk is commonly expressed as the likelihood of a threat exploiting a vulnerability multiplied by the impact on the asset. Risk treatment options are: avoid, mitigate (reduce), transfer (share), and accept. Any risk left after treatment is residual risk, and only an appropriately authorised business owner may accept it.

Compliance is conformance to external obligations (laws, regulations, contracts, industry standards) and internal obligations (policies). Compliance is a minimum bar, not a guarantee of security: a compliant system can still be insecure, and compliance should be viewed as an output of good governance and risk management rather than the goal itself.

Key Standards, Frameworks and Regulations You Should Recognise
ISO/IEC 27001 – Requirements for an Information Security Management System (ISMS); certifiable; uses a risk-based Plan-Do-Check-Act approach.
ISO/IEC 27002 – Code of practice / control catalogue that supports 27001.
ISO/IEC 27034 – Application security; introduces the Organisational Normative Framework (ONF) and Application Normative Framework (ANF), and the Application Security Control (ASC) concept.
ISO/IEC 27005 – Information security risk management.
ISO/IEC 15408 (Common Criteria) – Product security evaluation; Protection Profiles, Security Targets, Evaluation Assurance Levels (EAL1–EAL7).
ISO/IEC 12207 – Software life cycle processes.
ISO/IEC 25010 – Software quality model (security as a quality characteristic).
ISO 31000 – Generic enterprise risk management principles.
NIST SP 800-37 – Risk Management Framework (RMF): Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor.
NIST SP 800-53 – Security and privacy control catalogue.
NIST SP 800-30 – Guide for conducting risk assessments.
NIST SP 800-39 – Managing information security risk at organisation, mission and system tiers.
NIST SP 800-64 – Security in the SDLC (superseded but still referenced).
NIST SP 800-218 (SSDF) – Secure Software Development Framework: Prepare the Organisation, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities.
NIST Cybersecurity Framework (CSF) – Govern, Identify, Protect, Detect, Respond, Recover (CSF 2.0 added Govern).
FIPS 199 / FIPS 200 – Security categorisation (low/moderate/high by confidentiality, integrity, availability) and minimum security requirements.
FIPS 140-2 / 140-3 – Cryptographic module validation.
COBIT – IT governance and management framework from ISACA; aligns IT with business goals.
ITIL – IT service management best practice.
OWASP SAMM – Software Assurance Maturity Model; measures and improves secure development across business functions.
BSIMM – Building Security In Maturity Model; descriptive, based on observed practices in real organisations.
Microsoft SDL – Prescriptive secure development life cycle.
CMMI – Capability Maturity Model Integration; five maturity levels (Initial, Managed, Defined, Quantitatively Managed, Optimising).
PCI DSS – Payment card data protection; Requirement 6 addresses secure development and vulnerability management.
SOX – Financial reporting integrity; requires IT general controls, change control and separation of duties.
HIPAA / HITECH – Protected health information in the US.
GLBA – Financial customer data protection in the US.
GDPR – EU privacy regulation; privacy by design and by default, data subject rights, breach notification within 72 hours, data protection impact assessments.
CCPA/CPRA – California consumer privacy.
FISMA – US federal information security; implemented through the NIST RMF.
FedRAMP – Cloud service authorisation for US federal agencies.
SOC 2 – Service organisation attestation on Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy).
Safe Harbor / Privacy Shield / Data Privacy Framework – Mechanisms for transatlantic data transfer (note Safe Harbor and Privacy Shield were invalidated).

How GRC Works in the Secure Software Life Cycle
1. Governance sets direction. Executive management defines a security policy, assigns ownership, and establishes a security steering committee. Policies are mandatory and high level; standards specify mandatory technologies or configurations; procedures give step-by-step instructions; baselines set minimum configurations; guidelines are recommended but optional.

2. Risk assessment drives requirements. Assets are identified and valued, threats and vulnerabilities enumerated, and risk calculated either qualitatively (high/medium/low, heat maps) or quantitatively (Single Loss Expectancy = Asset Value x Exposure Factor; Annualised Loss Expectancy = SLE x Annualised Rate of Occurrence). The output feeds security requirements, threat models and the selection of controls. A cost-benefit comparison ensures the cost of a control never exceeds the value it protects.

3. Controls are selected and implemented. Controls can be classified by type (administrative, technical, physical) and by function (preventive, detective, corrective, deterrent, compensating, recovery). Control catalogues such as NIST SP 800-53 or ISO 27002 provide the menu; the risk assessment decides what to pick.

4. Compliance is verified. Internal audit, external audit and continuous monitoring confirm that controls are operating effectively. Evidence (logs, test results, sign-offs, configuration records) is retained. Gaps are tracked in a Plan of Action and Milestones (POA&M) or equivalent register.

5. Metrics and reporting close the loop. Key Risk Indicators (KRIs) and Key Performance Indicators (KPIs) are reported to management so that governance decisions can be revisited. GRC is a continuous cycle, not a one-time project.

Important Roles and Concepts
Data owner / business owner – Accountable for the asset and for accepting risk.
Data custodian – Responsible for day-to-day protection and operation of controls.
Data steward – Responsible for data quality and business rules.
Security officer / CISO – Advises, sets standards and monitors, but does not usually own business risk.
Due care – Doing what a reasonable, prudent person would do (acting). Due diligence – Investigating and continuously verifying that due care is being exercised (researching and monitoring). A common memory aid: Due Diligence = Do Detect; Due Care = Do Correct.
Separation of duties – No single person controls an entire critical process (e.g., developers should not promote their own code to production).
Least privilege and need to know – Grant only the minimum access required.
Risk appetite – The amount of risk an organisation is willing to pursue; risk tolerance – acceptable deviation from the appetite for a specific objective.
Total risk vs residual risk – Total risk is before controls; residual risk remains after controls and must be formally accepted.
Security vs privacy – Privacy regulations (GDPR, HIPAA) impose obligations beyond confidentiality, such as consent, purpose limitation, data minimisation and the right to erasure.
Legal considerations – Intellectual property (copyright, patents, trademarks, trade secrets), software licensing (including open-source licence obligations), export controls on cryptography, and contractual terms with suppliers and cloud providers.

Exam Tips: Answering Questions on Governance, Risk and Compliance Standards
Tip 1 – Think like a manager, not a technician. CSSLP questions are written from the viewpoint of someone who must align security with business objectives. When two answers look technically correct, prefer the one that references business risk, management approval, policy, or organisational process.

Tip 2 – Governance comes first. If a question asks for the first or most important step in establishing a security programme, look for management commitment, policy definition, or assigning accountability. Technical controls are never the first step.

Tip 3 – Risk drives everything. If asked what should determine which controls to implement, which requirements to prioritise, or how much to spend, the answer is a risk assessment. The cost of a control should not exceed the value of the asset or the expected loss.

Tip 4 – Know who accepts risk. Only the business or data owner (senior management) can accept residual risk. The security team, developers, auditors and project managers do not accept risk on behalf of the organisation.

Tip 5 – Compliance is a floor, not a ceiling. If an answer implies that being compliant means being secure, it is a distractor. Compliance must be verified through audit and continuous monitoring; it is not self-certified by the development team.

Tip 6 – Match the standard to its purpose. Memorise one-line descriptions: 27001 = ISMS certification; 27034 = application security framework (ONF/ANF); 15408 = Common Criteria product evaluation (EALs); 800-37 = RMF; 800-53 = control catalogue; 800-30 = risk assessment; 800-218 = SSDF; FIPS 140 = crypto modules; COBIT = IT governance; SAMM/BSIMM = maturity models (BSIMM is descriptive/observed, SAMM is prescriptive); CMMI = process maturity; PCI DSS = card data; SOX = financial reporting; HIPAA = health data; GDPR = EU privacy.

Tip 7 – Policy hierarchy vocabulary. Policy (mandatory, high level) > Standard (mandatory, specific) > Procedure (mandatory, step-by-step) > Baseline (mandatory minimum) > Guideline (optional recommendation). Questions often test whether you know guidelines are discretionary while standards are not.

Tip 8 – Quantitative formulas. Be ready to compute SLE = AV x EF and ALE = SLE x ARO, and to judge whether a countermeasure is cost-justified by comparing the ALE reduction to the annual cost of the control.

Tip 9 – Risk treatment options. Buying insurance or outsourcing is transfer; not launching the feature is avoid; adding a control is mitigate; documenting and signing off is accept. Ignoring risk is never a valid option and will appear as a distractor.

Tip 10 – Due care vs due diligence. Due diligence is the investigation and ongoing review; due care is the actual implementation of reasonable protection. Failure to do either can create legal liability (negligence).

Tip 11 – Watch for absolute words. Answers containing always, never, eliminate or guarantee are usually wrong. Risk is reduced and managed, not eliminated.

Tip 12 – Privacy is broader than confidentiality. When a question involves personal data, consider consent, purpose limitation, data minimisation, retention limits, breach notification timelines, and cross-border transfer restrictions, not just encryption.

Tip 13 – Read for the key qualifier. Words such as best, most, primary, first and least change the correct answer. Eliminate the two clearly wrong options, then choose between the remaining two by asking which better supports the organisation's business objectives and risk appetite.

Tip 14 – Separation of duties in the SDLC. Expect scenario questions where a developer deploys code directly to production, or a tester approves their own fixes. The correct remediation is a governance control (separation of duties, change management approval), not simply more testing.

Tip 15 – Frameworks are adaptable. Frameworks such as NIST CSF, COBIT and ISO 27001 are meant to be tailored to the organisation's size, sector and risk profile. An answer suggesting every control in a catalogue must be implemented regardless of risk is a distractor.

Quick Review Checklist
- Can you define governance, risk and compliance in one sentence each?
- Can you list the four risk treatment options and give an example of each?
- Can you explain the difference between total and residual risk and who accepts residual risk?
- Can you place policy, standard, procedure, baseline and guideline in order and say which are mandatory?
- Can you state the purpose of ISO 27001, 27034, 15408, NIST 800-37, 800-53, 800-218, COBIT, SAMM, BSIMM, PCI DSS, SOX, HIPAA and GDPR?
- Can you calculate SLE and ALE and justify a control on a cost basis?
- Can you distinguish due care from due diligence?
- Can you name the owner, custodian and steward roles and what each is accountable for?

Mastering GRC standards gives you the language to translate technical security work into business terms, which is exactly the mindset the CSSLP exam rewards.