In part two we identified who the threats are and what they’re after. That raises an immediate follow-on question: who in the organization is responsible for addressing them, 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. It’s the organizational framework that gives security its mandate, its authority, and its direction. Without it, security is advisory. With it, security has teeth.

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 from the security team will compensate 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.

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 each derives its authority from the layer above.

What Each Layer Does

Overarching Policy

The overarching security policy communicates management’s goals and objectives for the security program. It gives the security team its authority — without it, security practitioners are making requests, not enforcing requirements. It defines the function and scope of the security team: what they’re responsible for, what they have authority over, and where their mandate ends.

This document doesn’t get into technical specifics. It answers the question of why security exists in the organization and who owns it.

Functional Policies

Functional policies translate the overarching policy into domain-specific requirements. An access control policy defines how access is granted, reviewed, and revoked. An acceptable use policy defines what employees may and may not do with organizational systems. An incident response policy defines who is notified when, and what constitutes a reportable event.

These are still management documents, not technical ones. They set requirements. Standards and procedures are where those requirements get implemented.

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.

The Goals of Security

With governance established, it’s worth being explicit about what security is actually trying to protect and how. Security professionals work toward five core goals. Most people know the first three. The last two are just as important and often get less attention.

The right amount of security is proportional to the criticality of what you’re protecting. A publicly accessible marketing page and a database containing patient records don’t warrant the same controls. 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.

Cloud Computing and the Complexity Problem

Cloud computing changes the security conversation in ways that go beyond the shared responsibility model covered in part two. 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. That’s a data sovereignty problem, and it’s one that organizations moving to the cloud often discover late.

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. Data passing through certain countries may be subject to government access under local law. An organization operating in multiple markets may find that what’s legally compliant in one jurisdiction creates legal exposure in another.

On top of jurisdictional law, industry-specific regulations add another layer. Healthcare organizations must comply with HIPAA. Financial institutions face SOX and PCI DSS. Government contractors deal with CMMC and FedRAMP. These frameworks don’t disappear in the cloud — they follow the data. And moving to the cloud doesn’t make compliance easier. The shared responsibility model shifts who manages the infrastructure, but the regulatory obligation stays with the organization. Fortunately, many frameworks offer guidance on specific controls, giving you a documented baseline to work from rather than starting from scratch.

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.

Privacy is a right, not a feature. And increasingly it’s 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.

Organizations operating across multiple jurisdictions face a patchwork of obligations that can conflict with each other. The practical approach is to build a broad, sound baseline that satisfies the most stringent requirements across all markets, then address jurisdiction-specific differences on top of that foundation. It’s more work upfront but significantly easier to manage than trying to maintain separate compliance postures for each region.

Building a Privacy Program from Scratch

For organizations that don’t have a privacy policy or don’t know where to start, several frameworks provide structured guidance:

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.