The previous posts covered identifying threats and assessing risk — the analytical foundation of a security program. That raises an immediate question: who in the organization is responsible for addressing those risks, and with what authority? That’s a governance question, and it’s one a lot of security teams can’t answer clearly.
A security program built from the bottom up — practitioners implementing controls, hoping management notices and funds them — is structurally weak. It can produce good technical work in isolation but it will always struggle for resources, organizational buy-in, and the authority to enforce policy where enforcement is inconvenient. The controls are only as strong as the support behind them. Governance is what provides that support: the organizational framework that gives security its mandate, its authority, and its direction.
Tone from the Top
Effective security governance starts with the CEO. Not the CISO, not the security team, not IT. The CEO sets the organizational tone, and if security is treated as a priority at that level it flows down through every layer of the organization. If it isn’t, no amount of technical effort compensates for the gap.
The ideal structure is a governance committee chaired by the CEO, with representation from legal, finance, operations, HR, and the security function. The committee owns the overarching security policy, sets organizational risk tolerance, and makes decisions about resource allocation. It ensures security isn’t siloed inside a single department but treated as an organizational function that touches every part of the business.
Security decisions have consequences across the organization: budget, operations, legal exposure, employee experience. Those decisions need to be made at a level that can see the whole picture and be held accountable for the outcome. That’s not the security team — that’s executive leadership. Under ISO 27001, top management is required to demonstrate leadership and commitment to the ISMS. Under NIST CSF, governance is the function that sets and communicates risk tolerance to the rest of the organization. Without it, everything else in the framework is advisory.
The Policy Hierarchy
Governance produces a layered set of documents that flow from broad organizational intent down to specific technical implementation. Each layer is more specific than the one above it and derives its authority from the layer above.
Top Down, Not Bottom Up
The failure mode for most security programs is that they’re built bottom up. Practitioners identify risks, implement controls, and try to get organizational buy-in after the fact. It works until it doesn’t — until a control requires enforcement that only management can authorize, until a budget decision deprioritizes security, or until an incident happens and accountability is unclear because nobody with authority ever formally owned the program.
Governance built top down doesn’t have those problems. When the CEO chairs the governance committee and the overarching policy has executive sign-off, security decisions carry organizational authority. Controls can be enforced. Resources are allocated based on documented risk tolerance rather than whoever makes the most persuasive case in a budget meeting. And when something goes wrong, accountability is clear because ownership was established before the incident, not after.
A security team that builds its program without executive backing will always be fighting for legitimacy. They may be technically excellent but organizationally powerless. Governance is what converts technical competence into organizational authority — and it’s what regulators and auditors look for first when assessing whether a security program is real or performative.
The Goals of Security
With governance established, it’s worth being explicit about what security is actually trying to protect. Security professionals work toward five core goals. The first three are well known. The last two get less attention but are equally important — and both have direct compliance implications.
Confidentiality
Information is accessible only to those authorized to see it. Encryption, access controls, and classification schemes all serve confidentiality.
Integrity
Information is accurate and hasn’t been altered without authorization. Hashing, digital signatures, and audit logs support integrity.
Availability
Systems and data are accessible when needed. Redundancy, failover, and DDoS protection address availability.
Authenticity
Users and systems are who they claim to be. Authentication mechanisms — MFA, certificates, identity verification — establish authenticity.
Non-Repudiation
Actions can be attributed to a specific party who cannot credibly deny them. Digital signatures and comprehensive audit logging provide non-repudiation. Critical in legal, financial, and compliance contexts — AU-10 in NIST SP 800-53 addresses this directly.
The right amount of security is proportional to the criticality of what you’re protecting. Applying maximum security everywhere is as much a failure as applying too little — it drives up cost, creates friction, and ultimately leads to workarounds that undermine the controls you put in place. Security exists to support organizational goals, not obstruct them.
Cloud Computing and Data Sovereignty
Cloud computing changes the security conversation in ways that go beyond the shared responsibility model. One of the less obvious challenges is simply knowing where your data is. On-premises, data lives in systems you control, in locations you manage, under jurisdictions you understand. In the cloud, data can be replicated across regions, processed in data centers in multiple countries, and subject to laws you may not have considered when you signed the service agreement.
Jurisdiction matters because the laws governing data vary significantly by country and region. Data stored in the EU is subject to GDPR regardless of where the organization is headquartered. Industry-specific regulations add another layer — HIPAA, SOX, PCI DSS, CMMC. These frameworks don’t disappear in the cloud. The shared responsibility model shifts who manages the infrastructure, but the regulatory obligation stays with the organization.
Before moving data to a cloud provider, understand which regions your data will reside in and what laws apply there. Most major providers offer region-specific deployments and contractual commitments around data location — but you have to ask for them and verify them. The default configuration is rarely the most compliant one, and discovering a data residency problem during an audit is significantly more expensive than preventing it at migration time.
Privacy
Security and privacy are related but distinct. Security is about protecting data from unauthorized access. Privacy is about the right of individuals to control how their data is collected, stored, and used. You can have strong security and still violate privacy — a well-secured database that collects more data than users consented to is a security success and a privacy failure.
Increasingly privacy is also a legal obligation. Organizations that collect personal data from users in different regions may be subject to multiple privacy laws simultaneously, each with different requirements and penalties for non-compliance.
General Data Protection Regulation
EU regulation governing the collection and processing of personal data. Applies to any organization handling data of EU residents, regardless of where the organization is based. Broad rights for individuals including access, correction, and erasure.
California Consumer Privacy Act
California law giving residents the right to know what personal data is collected, the right to delete it, and the right to opt out of its sale. Applies to for-profit businesses meeting certain thresholds.
Children’s Online Privacy Protection Act
US federal law restricting the collection of personal information from children under 13. Requires verifiable parental consent and imposes strict requirements on operators of websites and services directed at children.
Organizations operating across multiple jurisdictions face a patchwork of obligations that can conflict with each other. The practical approach is to build a broad baseline that satisfies the most stringent requirements across all markets, then address jurisdiction-specific differences on top of that foundation.
Building a Privacy Program
Protection of PII in Public Clouds
A practical starting point for cloud-based environments. Extends ISO 27001 to address the protection of personally identifiable information in cloud services. Covers consent, transparency, data minimization, and processor obligations.
Generally Accepted Privacy Principles
Covers ten privacy principles including management, notice, choice, collection, use and retention, access, disclosure, security, quality, and monitoring. Useful as a comprehensive reference for building internal policy.
OECD Privacy Guidelines
One of the earliest international privacy frameworks. Foundational to many national privacy laws including GDPR. If your organization has no privacy program, this is a reasonable place to understand the underlying principles before working toward regulatory compliance.
Control Mapping
Governance isn’t just organizational structure — it maps directly to requirements in every major security framework. Without it, the technical controls in subsequent posts have no organizational authority behind them.
ISO 27001 Clause 5 (Leadership) requires that top management demonstrates leadership and commitment to the ISMS, establishes an information security policy, assigns responsibilities, and ensures that the ISMS achieves its intended outcomes. This clause cannot be satisfied by the security team alone — it explicitly requires organizational leadership involvement, which is the governance committee structure described above.
NIST CSF GV (Govern) is the function added in CSF 2.0 that addresses organizational context, risk management strategy, roles and responsibilities, policy, and oversight. GV.PO requires that organizational information security policies are established, communicated, and enforced. GV.RM requires that risk management objectives are established and agreed to by organizational stakeholders. Both require the top-down governance structure described in this post.
NIST SP 800-53 PL (Planning) family covers system security plans, rules of behavior, and security and privacy architectures — the policy hierarchy in practice. Without governance producing that documentation hierarchy, the PL family controls cannot be satisfied.
NIST SP 800-53 AU-10 (Non-Repudiation) requires that the system protects against individuals falsely denying having performed actions. This is the technical implementation of the non-repudiation security goal — comprehensive audit logging tied to authenticated identities. It’s one of the controls that frequently surfaces in legal proceedings and breach investigations, and it requires both governance (who is required to maintain logs, for how long, under what review process) and technical implementation.
With governance in place, security goals defined, and privacy understood as a distinct obligation, the groundwork is set for the next step: the controls themselves — what they are, where they go, and how they layer.
