Reading: The CISO Skill Nobody Talks About

There's a skill that underpins almost everything a CISO does, and it rarely shows up on job postings, conference talks, or LinkedIn thought-leadership threads. It's not "executive communication." It's not "risk quantification." It's not "building a security culture."

It's reading. Long documents. Cover to cover. Over and over again.

The Job Is Documents

Think about what a CISO actually touches in a given week. NIST 800-53 is over 400 pages. SOC 2's trust service criteria, the supporting points of focus, and the related guidance span hundreds more. FedRAMP authorization packages make those look like pamphlets. Then there are the incident reports, penetration test findings, vendor security assessments, data processing agreements, privacy policies across multiple jurisdictions, and (if you're doing your job) the policies and procedures you wrote yourself, which you need to reread more than anyone.

That's before you open your inbox.

I run security and engineering for a SaaS platform that serves over 400 universities. Our compliance surface includes NIST 800-53, TX-RAMP, CMMC, and HECVAT, and that's the shortlist. On any given day, I might be reviewing a penetration test remediation report, updating an access control policy, responding to a university's security questionnaire, drafting a data processing agreement for a client in the EU under GDPR, or confirming that our incident response procedures still match reality after an infrastructure change. Every one of those tasks starts the same way: reading.

Skimming Is a Liability

There's a difference between efficient reading and skimming, and too many people in security conflate the two. Efficient reading means you can move through dense material quickly while still catching the details that matter — the subtle difference between "should" and "shall" in a control requirement, the footnote that changes the scope of an entire control family, the one line in a 30-page vendor agreement that gives them permission to subcontract your data to whoever they want.

Skimming means you missed all of that and felt productive doing it.

I've seen security programs get tripped up not by sophisticated threats but by a paragraph nobody read carefully enough. A policy that said one thing while the procedure said another. A framework requirement that was technically met in letter but completely missed in spirit because someone copied language without understanding the context around it.

Your Own Documents Need It Most

Here's something that might sound counterintuitive: the documents you need to read most carefully are the ones you wrote.

I've authored over 900 pages of security policy documentation. I can tell you from direct experience that document blindness is real. When you're deep in the work of building out policy across the dozens of NIST control families (AC, AT, AU, CA, IA, SC, SI, and the rest) you know what you meant to say, so that's what you see on the page, even when the words say something slightly different. A policy or procedure gets versioned and updated a few times across a year, and little inconsistencies creep in. A control mapping drifts from the actual implementation. Section 4.2 contradicts Section 7.1, and nobody notices because nobody sat down and read the whole thing in sequence.

Auditors will, though. They read your documents with fresh eyes and no charitable interpretation. If your access control policy says reviews happen quarterly but your procedure says monthly, that's a finding. If your incident response plan references a team structure you reorganized six months ago, that's a gap. These aren't hard problems. They're reading problems.

When I go through a round of policy updates — remediating template artifacts, filling compliance gaps, incrementing versions — I have to read each document as if someone else wrote it. That's the only way to catch what's actually on the page versus what I remember putting there.

Frameworks Reward Close Readers

Compliance frameworks are not written casually. Every word in a NIST control is deliberate. The supplemental guidance exists for a reason. The discussion sections in SP 800-53 aren't filler — they're where you learn why a control exists, which is the only way to implement it in a way that actually makes sense for your environment. It's honestly impressive that they managed to fit it within 500 pages!

When you read frameworks deeply, you start seeing the architecture behind them. You notice the patterns, the way certain control families reinforce each other, the places where different frameworks overlap almost word for word and the places where they diverge in ways that matter.

This is something I've quantified. As part of ongoing research into compliance framework redundancy, I've analyzed over 1,400 controls across 15 frameworks. By the time you reach your fifth framework, nearly half the controls are redundant — you've already implemented them under a different name for a different standard. But you only discover that by reading each framework thoroughly enough to recognize the overlap. If you're treating each new framework as a completely fresh lift, you haven't read the ones you already have closely enough.

This kind of insight doesn't come from summaries or compliance platforms that reduce controls to checkbox items. It comes from sitting with the actual text.

The Dual-Role Multiplier

I'll add a wrinkle that's specific to my situation but probably resonates with more people than you'd expect: I'm not just the CISO. I'm also Principal Engineer. I write the policies and I write the code. I define the controls and I implement them. That dual role means I'm reading two completely different categories of dense documentation — security frameworks on one side, technical specifications and codebases on the other — and they both demand the same kind of careful, sustained attention.

In some ways it's an advantage. When I read a NIST control about session management, I know exactly how our platform handles sessions because I built it. When an auditor asks how we implement a specific control, I can trace it from the policy language through the procedure and into the actual code. But that only works if I've read all three layers carefully enough to know they're consistent.

If you're a CISO who also touches engineering, infrastructure, or DevOps — and in smaller organizations, that's a lot of us — the reading load doesn't split neatly. It compounds.

Building the Muscle

Reading long documents is a skill like any other — it atrophies without practice and improves with deliberate effort. A few things that help:

Read actively, not passively. Keep a notes document open. Flag inconsistencies, questions, and things you want to revisit. If you're reading a framework, write down how each control applies to your specific environment as you go. If you're reviewing your own policies, read them as an auditor would: literally, skeptically, and without any assumptions about intent.

Read in blocks, not marathons. Nobody absorbs 400 pages of NIST in one sitting. But an hour a day with a framework, consistently, will get you through it in a couple of weeks — and you'll actually retain it. Trying to speed-run a framework the week before an audit is how things get missed.

Reread things you think you already know. Frameworks get updated. Your own documents get updated. Your understanding of your environment evolves. Something you read a year ago might land completely differently now that you've been through an audit cycle, an incident, or a major infrastructure change. I've gone back to control families I thought I knew inside out and found gaps that only became visible after a year of operational experience.

Read adjacent material. Don't just read the control — read the guidance document that explains it. Don't just read your policy — read the procedure that implements it and then check if reality matches either one. Context makes individual documents useful. When you're juggling privacy laws across US states, GDPR, and international requirements like I do, reading one jurisdiction's rules in isolation will mislead you. The connections and contradictions only surface when you read broadly.

Tools Don't Read for You

I know what you're thinking. We have GRC platforms. We have compliance automation. We have AI that can summarize a 400-page framework in thirty seconds. Why does anyone need to read anymore?

Because tools process text. They don't understand it.

A GRC platform can map your controls to a framework. It can track completion percentages and generate dashboards that make your compliance posture look clean from a distance. What it can't do is tell you whether the control you implemented actually satisfies the intent behind the requirement, or whether your environment has a nuance that makes the standard mapping wrong. That judgment only comes from having read the framework yourself, deeply enough to know what it's really asking for and why.

Compliance automation tools are even more seductive. They promise to reduce frameworks to checklists, to turn hundreds of pages of nuanced guidance into a series of green checkmarks. I'm not dismissing them, they are useful. But the moment you start trusting the checkbox without understanding the control behind it, you've outsourced your professional judgment to a product that doesn't know your environment, your architecture, or your risk tolerance.

Then there's AI. And I say this as someone who uses AI tools constantly in my work (I've got a lot to share on that front in the future): AI is going to transform how we interact with compliance documentation. It already is. I can feed a policy document to an LLM and get back a gap analysis in minutes that would have taken me hours. I can ask it to cross-reference controls across frameworks and surface overlaps. That's genuinely powerful, and it's getting better fast.

But here's what AI can't do: it can't give you the intuition that comes from having actually read the material. It can tell you that two controls are textually similar. It can't tell you that they diverge in practice in ways that matter for your specific platform. It can summarize a framework's requirements. It can't replace the slow, compounding understanding you develop from reading those requirements in context, across multiple frameworks, over years of implementation.

If you haven't read the frameworks yourself, you can't evaluate whether the AI's analysis is right. You're not using AI as an accelerant — you're using it as a crutch. And the difference between those two things is whether you actually understand your own security program or you're just trusting that someone (or something) else does.

The CISOs who will get the most out of AI tooling are the ones who already did the reading. They'll use AI to move faster through material they already understand deeply. Everyone else will use it to move faster toward findings they don't see coming.

The Competitive Advantage You Don't Expect

In a field obsessed with tools, automation, and certifications, the ability to sit down and carefully read a 200-page document is quietly one of the most valuable things a CISO can do. It's not glamorous. Nobody's building a SaaS product around it. But it's the foundation that everything else rests on — your policies, your compliance posture, your audit readiness, your ability to actually understand the threat landscape beyond headline-level summaries.

The best CISOs I've encountered aren't the ones with the most certifications or the biggest budgets. They're the ones who've actually read the frameworks they're implementing. All of them. Carefully. And then went back and read them again.

If that sounds tedious, give it a chance before you write it off. It's an acquired taste. The first time you sit down with a 400-page framework, it feels like a chore. The tenth time, you start noticing things you missed — connections between control families, echoes of language across completely different standards, the way a single sentence in supplemental guidance reframes an entire requirement. You don't have to love it on day one. You just have to be open to the possibility that it becomes the part of the work you rely on most.

I'll be honest: I get excited now when NIST drops a new publication. A new SP, a new revision, a major research report — I genuinely look forward to reading it. Not because I'm wired differently than anyone else, but because I've done enough reading to know what I'm looking at and why it matters. That kind of engagement doesn't come from a natural love of dense government documents. It comes from the understanding that builds up, slowly, every time you do the reading instead of skipping it.

So if you're early in your career and the thought of reading 900 pages of policy documentation sounds miserable — I get it. It sounded miserable to me once too. Read it anyway. The version of you on the other side of that work will be a fundamentally better CISO for it. And eventually, you might even enjoy it.