Policy by design
Designate, situate, and empower
Against the backdrop of my earlier post on creating an information security policy, I’d like to now turn to some more concrete advice. My writing has always suffered from a kind of inductive structure, so I’ll try something new and give you the thesis first. An effective information security policy avoids codifying elements subject to change - rather, it defines and shapes the governance of those dynamic elements. It empowers subject matter experts to lead the selection and evolution of these elements, relying on stakeholders in organizational governance to ensure there is a match between organizational risk tolerance and the practical needs of cybersecurity practice. Bluntly put, infosec policy must move from technical control to structural agility.
Let’s begin by enumerating the goals for any infosec policy. We can return to each of these as a way to test any policy we’re drafting. First, it must advance the institutional mission. Second, it must effectively reduce risk. Third, as mentioned in the last piece, it should take steps towards establishing the principles of culture. Fourth - equally if not more challenging - it should both be natively maturing and self-auditing. Finally, a policy must be implementable - that is, without means-testing1 your policy, it is likely to fail.
While not on my list, I should say a few words about the clarity of the writing. Too many infosec policies are written by and for cyber professionals. Lord knows how much of my life I’ve wasted arguing with auditors about just what a policy says or means. The irony of me arguing for simple prose on this blog isn’t lost on me. Nevertheless, if your policy uses a term of art, question why it’s there. A policy can’t be followed if it can’t be understood.
Despite striving for clarity, I’ve long believed that any complex policy needs some form of exegesis, written by the policy team, that explains in plain language what the authors meant and what drove each element of the policy. More than an FAQ, but less than another policy. Policies are the distillation of a long process of discussion, debate, and analysis and far too much gets left on the cutting room floor, so to speak. So I’ll simply leave it with this: individuals throughout your organization need to be able to understand your policy without requiring an attorney or cyber professional to explain it to them.
While I’ll walk through all of the goals listed above sequentially, none of them should surprise anyone except for the fourth, that a policy should be both self-maturing and self-auditing. These feel aspirational, and probably don’t apply to the policy itself, so much as the infosec program that is engendered by the policy. It’s tempting to parse ‘self-maturing’ as a policy that evolves/improves over time without constant manual updates or governance structures that adapt and improve based on experience, that is, feedback loops. Self-auditing is simpler to define; a policy (or in this case program) the execution of which produces the evidence that it’s being performed. It’s also easier to imagine what this might look like - perhaps any process or control generates comprehensive evidence of its execution. Perhaps that’s some form of real-time metric aggregation or perhaps for some processes it’s merely a registration - a log entry - showing the process was performed. Neither of these truly address the need for an independent third-party to review and collect the evidence. Without this third-party review, we are not self-auditing but merely collecting telemetry.
I find the most difficult goal to address is the notion of advancing the institutional mission. I’ve written plenty on this question2 though I’m not sure how to capture in a pithy paragraph or three the tight coupling between mission and cybersecurity practice. Simple sentences such as ‘in order to protect the expansive role of academic freedom’ or ‘to ensure the integrity of data supporting the national health and security’ seem to assume a common understanding of the function of cybersecurity. Nor is there room in a simple policy for an extended essay on the question.
I also worry that it’s too easy to overreach - that is, to use language that is too ornamental - our present concern for information assurance is a modern one. While there is a long history of using ciphers for confidentiality, it’s difficult to identify a history for cybersecurity earlier than the 1960s. Essentially, there is a mismatch between the history of cybersecurity and the history of institutional principles. Thus we should recognize that this mismatched history is a constraint on rhetoric. This context should be seen as cautionary to anyone trying to couple cyber to foundational principles of the university3.
There is an argument to be made, however, that confidentiality and privacy, partnered with the notion of the ‘protection of digital systems and assets’ can be convincingly used to join information assurance with a university’s mission. Perhaps that offers us an effective hook and an opportunity to meld cybersecurity with culture as well as mission.
The standard response is that, rather than attempting to rhetorically elevate cybersecurity into the mission itself, an effective infosec policy should frame information assurance as an enabling condition for the mission’s execution - protecting the confidentiality, integrity, and availability of the digital systems upon which teaching, research, and public service now depend. But I don’t think this goes far enough. In a fully digital ecosystem, the protection of the privacy of thought becomes a necessary precondition for both forms of academic freedom: the freedom to explore and research without fear of repercussion (a faculty concern), and the freedom to learn and study without fear (a student concern)4. This is to say, an infosec policy is not merely about protecting systems, but about preserving the conditions under which intellectual risk-taking remains possible in digital environments5.
Finally, while discussing institutional mission it may be valuable to codify the multidimensional nature of the modern campus. That is, to recognize that different challenges require different practices for enterprise systems, highly regulated environments, and research environments, ensuring each is equally resourced. Essentially that modern universities have different missions and your policy should guide governance, implementation, and compliance actors to tailor and scale to each mission as appropriate.
Returning to my list of policy goals, I’ve included having the policy lower institutional risk. Which raises the question, does having an infosec policy lower institutional risk (or increase resilience) on its own? We’ve all seen institutions establish such policies but fail to resource or implement the practices such a policy requires. Every major organization, whether higher ed, commercial, or governmental surely has an infosec policy, yet the pace of failures only seems to accelerate. If one of our goals in creating an infosec policy is to lower institutional risk then it seems that policy should create mechanisms that directly address risk. In the early days of infosec policies we would enumerate a modest set of practices, such as requiring the use of antivirus software or strong passwords. As I’ve argued earlier, this approach results in policies that are unable to keep up with the rapid changes to the threat landscape, nor advances in technology.
Lowering risk means that our policy needs to create a structured, sustained, coordinated effort with dedicated resources to achieve specific goals. Policy reduces risk only insofar as it compels programmatic structure and accountability. It's more than ad hoc activities - it's formalized, ongoing, and systematic. It’s a program, not a project or an initiative. This creates a familiar policy design tension: policy must define enough structure to be meaningful, while stopping short of prescribing how each organization operationalizes it. I have to confess that as a policy author, I’d want to define what constitutes a program, to define its elements. As the subject of a policy, I’d chafe against being told how to create my program6.
I tried to thread this needle in my most recent work in this space, authoring §5.3 of the NSF Research Infrastructure Guide which includes the requirement for facilities to have an Information Assurance Management Plan (or IAMP)7. Which is less a program statement, but rather a summary of how one’s information assurance program is run. Think of it as a disclosure statement. The goal of creating an IAMP isn’t to manage the management of cybersecurity, but to force an organization to articulate how they’ve chosen to do so, and to have senior management sign off on that program. It doesn’t name a specific standard or framework, but requires the organization to do so. It doesn’t require a set of functions (such as intrusion monitoring) but does require the organization to enumerate the functions they’ve put into place. The IAMP gives management a short descriptive program statement and thus becomes a vehicle for conversations around resourcing8.
Of course, whether one is creating a program of study within an academic unit or a program of information assurance, it must be situated within an existing management structure - or one must be created for it. While an IAMP will necessarily contain detailed descriptions of roles, responsibilities, and operational practices, it is, by design, a living document that evolves over time. For that reason, establishing persistent oversight, authority, and accountability at the policy level is not merely appropriate but necessary.
I feel compelled to interject an aside here. As I prepare to say something like “your infosec policy should mandate the creation of an IAMP with the following elements,” similar to how it’s stated in the Research Infrastructure Guide, I question if even that is too prescriptive and thus ultimately ephemeral. As before, the tension is between durability and specificity. I always find myself questioning why IT and cybersecurity seem to need an entirely distinct class of governance and policies than those that guide the rest of the institution. Do we mandate that the procurement office create an operating manual and have it approved by some senior manager? Or am I being influenced by the momentum of poorly structured legacy policies that our institutions have acquired over the decades? Even the traditional hierarchy we in cybersecurity rely on - principles → policy → standards → procedures → guidelines - seems poorly embraced by ordinary non-IT operations. I persist in my view that good policy is about how decisions are made, not what decisions must be made.
We seem to have arrived at a critical junction - if good policy is about how decisions are made, then we need to define who makes those decisions and who is accountable for implementing them. This strikes me as the core of how an organization wants information security to function. Does your policy simply say cybersecurity is in the portfolio of the CIO? Or is the CISO named as an institutional officer vested with formal authority and decision-making rights? Is cybersecurity boxed into securing systems and services, and if so, where and how is organizational resilience managed? Where does cybersecurity end and resilience begin? I recall running a tabletop exercise once, focused on attacks on part of the campus power infrastructure. The head of facilities said that when power mysteriously went down, he’d send out some electricians. When the chancellor asked if he’d notify my office (the security office) he stared blankly into space, never had the thought even occurred to him. This anecdote illustrates part of our challenge, that organizational boundaries, not threats, determine response pathways. And this is exactly why policy must explicitly define decision-making authority and coordination mechanisms - otherwise, everyone operates in their lane while threats cross all lanes.
Where I see cybersecurity struggle within traditional governance frameworks is with pace. Having sat for more than a decade on various faculty senate committees, I watched one issue (closing an institute that produced 4 students a year) get debated for ten years without resolution. As a CISO I watched fear, uncertainty, and doubt delay an urgent mass password change to stretch over six months rather than the two weeks circumstances warranted. The irony is stark: we have enormous tolerance for potential cyber risks, but absolutely zero tolerance for the risk of annoying faculty and staff or getting too many calls to the help desk. The political cost of action being more salient than the abstract cost of risk. This is not (just) the idle whining of a frustrated CISO, but may be the essential tension of the web connecting cyber professionals and organizational governance.
Ultimately we’re talking about authorizing the designated decision maker (let’s call it the CISO for now) the authority to move forward with some classes of controls on her own authority, while others may require a greater degree of review and debate. This implies working out a taxonomy of decisions. Perhaps a few examples would be helpful. I recall a colleague at a peer campus telling me that 80% of their ransomware attacks were mediated by compromised VPN accounts. We moved quickly in response and within 6 weeks had added MFA to our VPN login process. When our procurement office had payments redirected by someone who socially engineered changing banking information, they decided to outsource the handling of banking information to a third-party. This not only raised the bar on validating the information, but also gave the university a liability shield for the vendor took on the risk of failure.
The first of these is the imposition of a classic cybersecurity control: MFA on VPN is a technical control with known efficacy. The second is a kind of risk management control enhancing organizational resilience: a risk transfer and resilience decision. In the first, I was able to make this happen solely on my own authority - though obviously I still socialized it with our executive leadership9. The second was vetted, analyzed, and discussed broadly within procurement services, and finally ‘authorized’ in that procurement needed the funding to pay for the service.
What role should any governance play in either of these scenarios? For the former I’d argue none. While the savvy CISO will be sensitive to impacts on research and academic activities, isn’t this precisely the kind of technical response to risk one would want from your security leadership? For the latter, the process was much more deliberate - that is, until the funds were stolen; then the project was moved off the back burner and quickly implemented. I have no doubt we can all think of any number of similar scenarios, situations that are useful when evaluating how to build a governance process in your infosec policy.
The distinction between them, however, illustrates a critical difference in authority. If an institution wants to move from reactive to proactive it must delegate decision-making authority ex ante, that is, granting someone the power to make decisions before a specific event occurs, rather than asking for permission on a case-by-case basis10.
You can see that I’ve stacked up a number of decisions that need to be made prior to drafting your infosec policy, none of which are unique to cybersecurity, but instead go to the dimensions of governance. What is your taxonomy of decisions that your designated decision maker can make without requiring approval? And what is the class of decisions that can be made as needed, in advance of an incident? With regard to governance, what is its role when these ‘approval-free’ decisions are made? I would argue that it is to help the decision maker with the institutional context - to understand where the various pitfalls exist and to assist with advocating for and communicating about an upcoming change.
All of this is to emphasize that if you want your governance process to support and not hobble cybersecurity, it’s important to remember that governance is not a checkpoint or an approval queue; nor is it a substitute for expertise. Governance as I’ve described it becomes contextual intelligence, institutional memory, political cover, and part of the communications infrastructure.
Naturally you may be waiting for a discussion of what sort of decisions should require approval. I’m having trouble characterizing these outside of the dimension of cost. Returning to my earlier discussion of strategic decisions, decisions that have a long time horizon, are difficult to reverse, require changing organizational boundaries, and require significant new expertise - it’s hard not to see all of these as proxies for ‘costly’ or ‘disruptive’. Both of which are signals for governance and executive involvement. I’ve written previously on strategic decisions11, and I’ve spilt enough electrons on the issue of governance in this post, so I’d like to move on, perhaps unpacking the question of the role of governance as an approval engine is worthy of a separate post.
I should say a few words about the importance of implementability - essentially, means testing your policy. I used to mock the obsession some organizations have around policy while ignoring the boots on the ground issue. “Keep your policy and give me a few more staff, and I’ll lower risk” was my response to audit and policy committees. But I know I’m not alone in having this attitude, the under-resourcing of security offices may be the salient feature of higher education’s approach to cybersecurity. While questions of funding cybersecurity go to the heart of institutional complexity, we have to move past including cybersecurity funding needs as a mere line in the general IT budget. Yes, enterprise systems need to earmark the cybersecurity resources required by those systems, but the agility, responsiveness, and pace required by modern risk and resilience practices demands a different model for funding. I can think of no better function for a security governance committee than helping evaluate the resource needs for ongoing operations and new initiatives and advocating with institutional leadership for those resources12.
Policy reduces risk through structure, not lists. That’s the core insight from what’s probably been my longest post. Effective information security policy should focus on governance - who decides, how authority is delegated, how accountability is sustained - rather than codifying technical controls that rapidly become obsolete. Good policy advances institutional mission by framing information assurance as both an enabler of academic work and a necessary precondition for academic freedom in digital environments.
Policy works by compelling durable programmatic structure: resources, authority, and clear decision-making pathways. Mechanisms like Information Assurance Management Plans force organizations to articulate how cybersecurity is governed and resourced while preserving implementation flexibility. The core challenge is governance: defining decision-makers and delegating authority ex ante so security leaders can act at the pace threats require. Governance should provide contextual intelligence, institutional memory, and political cover, and not function as an approval queue. Implementable policy requires institutional capacity: staffing, funding, decision rights. Without resources and clear governance, policy becomes symbolic rather than effective.
I want to try to conclude by reducing my recommendations to three elements: designate, situate, and empower.
At a 50,000-foot level I’d like to see the infosec policy designate a decision maker, place that decision maker into a new or existing governance structure, and articulate the decision making rights both ex ante and ex post as discussed above. The policy must empower the decision maker to manage and expand a set of mandatory risk management controls, and assign responsibility for the implementation of these practices. Too many security programs become constipated by having to negotiate the why of a security control with stakeholders, when the more valuable question is the how of a security control. Recognition and acknowledgement of subject matter expertise is implicit in the designation of a decision maker13.
Cybersecurity forces institutions to confront the limits of consensus-driven governance in operational risk domains. It should be obvious that I’m walking a narrow path between two chasms. On one hand I want to greatly empower the CISO as the SME for cybersecurity to act on the best professional guidance the field has to offer. On the other, as an institutionalist, I realize that it is unreasonable and unprecedented to cede such broad authority to what is in effect a middle manager. Remember the breadth of scope and impact issues of cybersecurity and resilience have across an institution. I am not arguing for unchecked CISO power, but rather a reallocation of decision rights consistent with risk and pace.
At its simplest, I see an institution’s policy designating the CISO to lead information security, with the authority to add, modify, or remove required practices from some sort of security practice registry14. I see the governance process as supporting the CISO’s mission, approving and advocating for resilience measures that exceed the immediate capacity of the CISO’s remit.
There are plenty of reasons to be cynical about governance committees. But we can’t assume that all decision-making collapses into committee politics. Governance bodies succeed or fail based on how clearly decision rights and escalation paths are defined. This must be addressed directly in your policy, for authority must be legible and explicit even when exercised collectively.
Finally, I do see it as appropriate for the policy to explicitly require an Information Assurance Management Plan (or whatever you want to call it), with specific elements identified15.
Ultimately, the goal of an information security policy is not to produce a document that sits on a digital shelf, but to move the institution past the era of the “blank stare” by cultivating a shared vocabulary of risk and responsibility. Information security is the digital manifestation of institutional resilience: by defining authority ex ante, codifying mechanisms such as an Information Assurance Management Plan and a security practice registry, and reframing governance as contextual intelligence rather than a checkpoint, policy provides the legibility governance requires without sacrificing the pace security demands. We hire CISOs for their expertise; we should write policies that allow them to use it. In doing so, we protect not only systems, but the privacy of thought that underwrites academic freedom - thus ensuring that when threats cross all lanes, every actor understands both their role and the pathways that connect them.
I’m somewhat abusing the term ‘means testing’ throughout this essay. I’m extending its definition to mean “testing if the policy is implementable with the existing resources”.
The series on the role of information assurance seems to capture much of it.
I once created a kerfuffle when a number of faculty accused me of running roughshod on academic freedom and their role in shared governance by quoting the university’s founding statutes in support of academic freedom in a policy draft. Statutes that had been in place for over 120 years. No good deed, indeed.
When engaging faculty, I do worry that focusing on the threat of covert surveillance is merely exchanging one form of security porn for another. That is, in place of the threat of breaches and hacks we’re raising a more sinister specter, sinister because of its invisibility. There are probably a number of ways to approach this, however I’m attracted to pivoting away from ‘cybersecurity as a defense’ towards ‘cybersecurity as a toolset’ provided by the institution; a toolset that offers faculty some degree of control.
As a community of cyber practitioners, we do a poor (and overly defensive) job of explaining how technologies such as pervasive logging, behavioral analytics, or research monitoring support the privacy of thought and academic freedom. Too often we fall back on “it’s simply necessary in the modern world”; albeit this is true, but counterproductive in building trust.
Perhaps that is just the hubris of age and experience. When I started in infosec I was hungry for guidance and direction.
I do want to remind the close reader that, like any agency policy document, a host of others contributed to that section. Some through conversation that steered the document, others by participating in its editing and finalization.
I would argue that the IAMP could serve as a template for institutions needing to create a research cybersecurity program to comply with the requirements of NSPM-33.
I should underscore that while I authorized and ran this mini-project, there was a legion of messaging and ad hoc presentations on why we were doing this so quickly.
While I haven’t thought this through, I do wonder if the differentiator between CISOs is that over time, the institution tacitly grants more successful CISOs increasing degrees of freedom - that is, the ability to make decisions before an event forces the institutional hand, so to speak. I would imagine this could be a useful direction to explore during an interview with a potential employer.
In discussing the role of the CISO and the paradox of anticipatory defeat.
I suspect that those of us in security leadership roles are our own worst enemies at times. We say that we need to implement something, we’re not funded for it (at all or appropriately), but we ‘make do’. We implement without adequate staffing or resources at the cost of eroding other services. We celebrate the heroics, but ultimately this rewards the institution at the cost of your staff’s health, creating an illusion of resilience.
It goes without saying that this brings a host of implications with it - both for the institution in its choice of decision maker, and the individual selected. It requires both to view this through the lens of professionalization.
I’m using the term ‘practice’ here deliberately. While as a term of art ‘control’ is fine, for end users control has unfortunate linguistic connotations and in the spirit of the NIST control sets be overwhelmingly granular. Take MFA for example. In essence, while not a standalone “MFA” control, the concept and implementation of MFA are embedded within multiple controls, especially in the Identification and Authentication (IA) and Access Control (AC) families.
I haven’t said anything about metrics or outcomes, mostly out of exhaustion. While I see a future post on metrics, it is worth saying that I’m skeptical of the classical risk measures so often used in cybersecurity. They feel a bit like pseudo-science. I am in favor of program completeness and outcome metrics as a pragmatic response to the difficulty of scaling traditional risk assessment methods across a large campus. This refocuses security efforts on achieving tangible, measurable maturity rather than simply ticking off compliance boxes.