Security Governance Principles
Evaluate, apply, and sustain security governance principles — alignment, frameworks, due care, due diligence
Security governance is how security aligns with business objectives. It's the managerial core of Domain 1 — and the mindset the entire CISSP exam tests.
Governance answers "what should we protect and why?" Management answers "how do we protect it?" The board owns governance; the CISO implements it. Every security decision must trace back to a business objective.
Two concepts define whether governance is working:
Due care — doing what a reasonable person would do ("we installed a firewall")
Due diligence — verifying those measures work ("we tested the firewall quarterly")
Skip the second part and you have negligence — even if you bought every tool on the market.
At a company with mature governance, security is a top-down function:
- The board sets risk appetite and approves the security strategy. They don't configure firewalls — they decide how much risk the business will accept.
- The CISO translates board direction into a security program. Reports to the board or C-suite, not buried under IT.
- A security committee coordinates across business units — because security touches legal, HR, engineering, finance, and operations.
- Frameworks provide structure:
- ISO 27001 — the international standard for an ISMS (certification available)
- NIST CSF — a voluntary framework (Identify, Protect, Detect, Respond, Recover)
- COBIT — an IT governance framework (not a standard)
- SABSA — a security architecture framework
The exam tests the distinction: ISO 27001 is a standard (you can be certified). COBIT and NIST CSF are frameworks (you adopt them). ITIL is best practices (optional guidance). Getting this wrong is a common trap.
| Framework | Type | Origin | Best For |
|---|---|---|---|
| ISO 27001 | Standard (certifiable) | ISO/IEC | ISMS establishment and certification |
| NIST CSF | Framework (voluntary) | US NIST | Risk-based security management |
| COBIT | Framework | ISACA | IT governance and management |
| SABSA | Framework | SABSA Institute | Security architecture |
| PCI DSS | Standard (industry) | PCI SSC | Payment card data protection |
| FedRAMP | Program | US Government | Cloud service authorization for federal use |
| Concept | What It Means | Example | Failure = |
|---|---|---|---|
| Due Care | Doing what's reasonable | Installing a firewall, writing a policy | Negligence |
| Due Diligence | Verifying it works | Testing the firewall quarterly, auditing compliance | Negligence (even with due care) |
Standard vs. Framework vs. Best Practice — the exam's favorite governance distinction:
Standard = certifiable, auditable (ISO 27001, PCI DSS)
Framework = voluntary structure to adopt (NIST CSF, COBIT, SABSA)
Best Practice = optional guidance (ITIL)
If the question asks "which can your organization be certified against?" — only standards qualify.
You're the security lead at a mid-size fintech. An audit just revealed a mess.
The Encryption Chaos
Fintech · 600 employees · 4 dev teams · No encryption standardThe governance failure: There's no policy. Jumping straight to a technical mandate (AES-256 everywhere) is a bottom-up approach — IT dictating to the business. It will face resistance, lack funding, and create inconsistency.
The governance solution (top-down):
- Step 1: Write an enterprise encryption policy — "all sensitive data must be encrypted at rest and in transit"
- Step 2: Derive standards from the policy — "AES-256 for data at rest, TLS 1.3 for data in transit"
- Step 3: Create procedures — "to encrypt a database: use this library, follow this key management process"
- Step 4: Get management approval and budget
The hierarchy matters: Business Objectives → Policy → Standards → Procedures → Technology. Always top-down. A standard without a policy has no authority. A technology choice without a standard has no consistency.
In practice, the CTO's instinct isn't wrong — it's just premature. You'll probably end up with AES-256. But mandating it without the governance structure means Team C keeps their custom wrapper because "nobody told us to change," and Team D ignores it because "we're not covered by this." Policy first, technology after.
On the exam: When you see "multiple teams doing different things," the answer is never "pick the best technical option." It's always "establish policy and standards first."
Your company is acquiring a smaller competitor. The CTO wants to connect both corporate networks immediately to begin integrating systems. "We need to show synergies to the board by Q3." The acquired company has no documented security policies, and their last penetration test was 3 years ago.
Connect networks with a firewall between them
Technical control reduces risk while enabling integration. Run a vulnerability scan after connecting.
Conduct a risk analysis before any network connection
Governance requires understanding the risk posture of the acquired company before introducing it to your environment.
Option B is correct — risk analysis before action, always
Option B: Connecting an unknown network to your environment without a risk assessment is introducing unquantified risk. The acquired company could have compromised systems, weak credentials, or active threats. A firewall (Option A) is a technical control applied without understanding what it's protecting against.
Option A's kernel of truth: A firewall is a reasonable control — but it's Step 3, not Step 1. The governance sequence is: (1) risk analysis, (2) define security requirements for the acquired network, (3) implement controls, (4) connect with monitoring.
On the exam: when a question asks about M&A, divestitures, or organizational changes, the first step is always a risk analysis — not a technical implementation. This is the "first step" trap the exam loves.
Three governance traps to watch for: (1) The bottom-up trap — any answer where IT drives the security initiative instead of management is wrong. (2) The technical fix trap — "patch the vulnerability" sounds right but the governance answer is "notify management" first. (3) The first-step trap — when a question asks what to do FIRST, it's almost always administrative (risk analysis, management approval) not technical. The hierarchy in your head should be: Business Objectives → Policy → Standards → Procedures → Technology.
- A Mandate AES-256 across all teams immediately
- B Develop and enforce an enterprise-wide encryption policy and standards
- C Hire a cryptography consultant to evaluate each team's approach
- D Outsource encryption management to a third-party provider
Correct: B. The CISSP mindset emphasizes policy, governance, and consistency over ad-hoc technical fixes. Option A jumps to a technology mandate without governance backing — a bottom-up approach. Option C delays action. Option D outsources without establishing internal standards first. Policy before technology, always.