Chapter 1: The As-Built Standard

Every information security program starts with design drawings.

Whether you inherited a security program or you’re building one from scratch, somewhere in that first month you sketched out the architecture you wanted: framework controls mapped to every system, clean data classification tiers, and a policy repository where everything cross-references perfectly. Maybe you even color-coded it. The mental image was perfect.

Then reality hit.

Budget cuts landed before you could hire your second analyst. The medical school runs its own IT and won’t return your calls. A “temporary” authentication workaround from 2019 is now critical infrastructure. The registrar’s office bought a new cloud service last Tuesday and didn’t tell anyone.

Your design drawings are already obsolete.

In construction, architects produce two sets of documentation. The design drawings show what the building should look like: clean lines, perfect specifications, everything in its place. Then there are the as-built drawings, created after construction is complete. These show what got built: the electrical conduit that had to route around an unexpected beam, the HVAC duct that shifted six inches so the door would open, and the structural reinforcement added when the soil report came back worse than expected.

As-built drawings are messier than design drawings. But they’re the only accurate map of the building. When something breaks twenty years later, you don’t reach for the architect’s original vision. You reach for the as-built documentation because that reflects what’s there.

The same gap exists in every university’s security program.

Generic frameworks (e.g., NIST, ISO, or CISA) tell you what a security program should look like. They’re design drawings. Comprehensive, well-organized, theoretically complete. But they don’t tell you what was built at your university. They don’t tell you which policies survived contact with shared governance, decentralized IT, academic freedom expectations, and six-month board approval cycles. They don’t tell you what to prioritize when you have three staff to support forty competing compliance obligations.

This framework bridges that gap with real-world data on what gets built, documented through direct observation across higher education.

But first, we need a name for what we’re looking at.

Every university has a gap between the security program they designed and the program they operate. Policies that were approved but never published. Standards that exist as institutional knowledge but were never written down. Controls that cover one regulation but miss two others. Practices that worked when one person managed them, but that person left three years ago.

We call that accumulated distance Governance Debt.

Governance Debt is like deferred maintenance. Every year that a patching standard goes undocumented or an access review process lives in someone’s head instead of a written procedure, the cost of formalizing your program grows. And when an auditor arrives, or your team struggles with communication plans during a malware outbreak, or a federal sponsor asks to see your compliance documentation, you discover the debt has come due.

This guide helps you measure Governance Debt, understand where it accumulated, and pay it down systematically before something forces your hand.

Chapter 2 shows how Governance Debt is distributed across the sector, measured by the 2026 Edition of the framework. But first, the case for why measurement matters.

Higher education faces a technology threat landscape that’s growing faster than most institutions can adapt. Governance Debt doesn’t cause security incidents, but it makes institutions less prepared to prevent them, slower to respond, and more exposed to the fallout.

The threat landscape is real and accelerating.

Education has become one of the most-attacked sectors in the world, and the volume is still rising. Chapter 2 documents the trend in detail. The pressure reaches even the best-resourced institutions. In 2023, Stanford University experienced three separate security incidents, with the Akira ransomware group claiming exfiltration of 430GB of data ¹. Carnegie Mellon disclosed unauthorized access to personal information of over 7,300 individuals ². The University of Michigan suffered a breach affecting 230,000 students, faculty, and staff ³.

These are well-resourced institutions with large dedicated security teams. Smaller institutions face the same threats with fewer resources to respond.

Compliance failures now carry real legal consequences.

Compliance risk is no longer theoretical. Georgia Tech Research Corporation paid $875,000 to resolve allegations that its Controlled Unclassified Information (CUI) protection program didn’t meet federal requirements ⁴. Penn State settled a False Claims Act lawsuit over similar research compliance attestation gaps for $1.25 million ⁵. The GLBA Safeguards Rule puts federal student aid eligibility at risk for non-compliance ⁶. And CMMC 2.0 requirements (finalized in late 2024 ⁷) added another layer of contractual obligation for institutions conducting defense-related research.

Institutions that haven’t invested in their policy frameworks and compliance programs are finding themselves exposed, not just to security incidents, but to legal liability.

None of this means a strong program prevents every incident. There is no such thing as absolute security, and even a well-built information security program will still face incidents, breaches, and hard audits. That isn’t a contradiction. It’s the nature of risk management, where the goal is never to eliminate risk but to manage it deliberately so the institution can absorb what it can’t prevent. You might see an institution held up as a model in one chapter of this guide and cited as a cautionary example in another. That’s the point, not an oversight. It reflects the world we actually work in.

Regulatory fragmentation multiplies the burden.

Most institutions face overlapping (and sometimes conflicting) requirements. For example, a student health clinic record might be subject to FERPA’s “reasonable” standard, HIPAA’s prescriptive controls, and NIST 800-171’s detailed specifications.

Without a unified governance approach, you might end up maintaining separate compliance programs for each regulation. Audit costs grow every year, and the gaps between programs make it easier for things to fall through.

So what does it look like when Governance Debt is paid down and your program is working?

• It looks like a board-level policy that delegates security authority to the CISO so technical standards can be updated as threats evolve without waiting for 12-month approval cycles.
• It looks like a single data classification scheme where a system handling student health records gets controls that satisfy FERPA, HIPAA, and state breach laws simultaneously.
• It looks like one encryption standard, properly documented, that satisfies GLBA, HIPAA, and PCI-DSS requirements at the same time.
• It looks like a college sysadmin who follows the institutional server hardening standard and knows the next auditor will find compliant systems.
• It looks like a GLBA auditor who asks about access controls and gets pointed to the same documentation you showed the HIPAA auditor last month.
• And it looks like a researcher whose request for a specialized analysis tool gets approved in 48 hours through a streamlined exception process, instead of being blocked by a blanket prohibition.

The goal in establishing robust policies and standards isn’t documentation for its own sake. We create IT and security policies that enable the institutional mission rather than obstruct it.

This book gives you a blueprint.

You’ll find a framework of 17 policies and 24 standards that captures what well-developed higher education programs have in common. You’ll find a set of structural loads (regulations, threats, and operational realities) that your framework has to support. You’ll find an operational model for handling the loads without building a separate compliance program per regulation. By the time you finish the book, you’ll have a blueprint template and the tools to adapt it.

But a blueprint is not a building.

No two higher education institutions have identical IT policies and governance structures. A community college’s policy library looks different from an R1 research university’s, and it should. A small liberal arts college manages governance differently than a public land-grant with a medical school and a defense research portfolio. If you over-engineer your program for requirements you don’t face, you waste resources and alienate your campus. If you simply copy a peer’s policy library without understanding your own obligations, you create structural blind spots.

The blueprint tells you what’s possible. You still have to build the building.

The rest of this book helps you do that. It shows you how the blueprint was developed, what it contains, how the loads vary across institution types, and how to adapt the template to your own site. Then it walks you through measuring what you have against what the blueprint describes, and turning the gap into a plan.

Chapter 2 presents the 2026 Edition of the CampusCISO IT Policy Framework. We reviewed 410 institutions, identified three diagnostic patterns that repeat across the sector, and documented where the gaps fall. It measures Governance Debt across higher education. These findings will refresh each year. The other chapters in this guide largely will not.