The Five Pillars of Information Security (And Why We Audit Accessibility)
Rietta is a cybersecurity firm. So why have the last three posts on this blog been about missing document titles, undefined languages, and metadata fields in government PDFs? My reasoning comes down to this: accessibility failures are security failures, specifically, they’re availability failures, and detecting them at scale is exactly the discipline our industry already practices.
To explain why, it helps to back up and lay out the actual model we use to reason about security in the first place.
The Five Pillars of Infosec
Most people who’ve spent time in security have run into the CIA Triad: Confidentiality, Integrity, and Availability. It’s a good starting point, but it’s incomplete for how modern, internet-connected systems actually get attacked and defended. The fuller five-pillar model, adding Non-Repudiation and Authentication, has its own long history: these same five properties, Confidentiality, Integrity, Availability, Non-Repudiation, and Authentication, are what DoD Directive 8500.1 defined as the core goals of Information Assurance back in 2002, under the acronym CIANA. “Five Pillars” is the more modern, pedagogical name for the same underlying model, not a term the DoD directive itself used. I can speak directly to how long I’ve been teaching and applying it: it’s been a named module in my threat modeling and application security workshops since at least 2019 (delivered through what was then DevelopIntelligence, later acquired by Pluralsight, for corporate clients including a Fortune 500 retail company), and it’s remained a fixture of Rietta’s own internal application security training ever since.
The five pillars of information security are:
- Confidentiality: protecting information from those who shouldn’t see it
- Integrity: preventing information from being changed outside the intention of its owner
- Availability: making sure the system and its information are actually reachable by the people who need them
- Non-Repudiation: preventing someone from credibly denying an action they took
- Authentication: confirming a user really is who they claim to be, and is authorized to be there
These pillars are often cited as the CIANA model, which expands upon the old CIA Triad. The classic triad still lives inside this model: Confidentiality, Integrity, and Availability are the first three pillars. The CIANA model is useful for grounding proactive threat modeling in a world with no real network perimeter left. The moment your server makes an authentication decision, that’s your actual security boundary, not a firewall. Non-Repudiation and Authentication earn their own pillars because so much of modern risk lives exactly there.
For years, I’ve asked my workshop attendees this: which of these five properties do people almost never think of as a security concern? Sometimes one or two will raise their hands, but usually I have to give the answer myself.
The answer is Availability. And that’s exactly where accessibility comes in.
Availability isn’t just “the server didn’t go down”
Availability, properly defined, means an authorized user can actually get to the resource they’re entitled to use. Most people hear that and picture uptime monitoring, DDoS mitigation, load balancers. All true, but incomplete.
Consider a government document that a blind resident, using a screen reader, cannot navigate because it has no defined document title, no language metadata, and no structural tags. The document exists, the server is up, and there was no breach, yet the intended user still can’t access the resource they have a legal right to use. That’s an availability failure, just as real as a server outage, even though nothing “went down.”
This isn’t a rhetorical stretch to justify a new business line. It’s a direct application of a pillar that already exists in the standard model, applied to a population of users the model has always technically covered but that most practitioners never think to apply it to.
Why a cybersecurity firm, specifically
The second half of the answer is about who is actually skilled to do this work well.
ADA Title II compliance for government entities isn’t a design problem you solve once. It’s a detection-at-scale problem: thousands of PDFs, Word documents, and spreadsheets, each with potential metadata deficiencies that compound legal exposure. That is structurally identical to what a vulnerability management program does with a codebase or an infrastructure footprint: systematic scanning, prioritized findings, remediation guidance, and repeat.
This is the reason Rietta built Metadata Minder, it’s the audit methodology behind our own Digital Accessibility Audits, and it’s the same audit methodology we already apply in our Authentication and Access Control assessments, where this same Five Pillars slide has been referenced in our service documentation since at least 2025.
Why this framework, and why now
I didn’t personally originate the five-pillar model; that lineage runs back through DoD information assurance doctrine. But I’ve taught and applied this exact framing since at least 2019, through corporate security awareness training and through Rietta’s internal “Practical Application Security Awareness” course. It also underlies the security chapter I contributed to the 7th edition of Fundamentals of Database Systems (Addison-Wesley). It’s a durable enough model that its underlying questions, whether a system’s integrity, availability, or authenticity was actually compromised, are the same ones that come up in serious incident response and forensic work generally.
What’s new here is naming a connection I haven’t seen made publicly elsewhere: accessibility is an availability problem, and treating it as one is why a cybersecurity firm belongs in this work.
What’s next
This is the first post in a series. We’ll cover each pillar, Confidentiality, Integrity, Availability, Non-Repudiation, and Authentication, with real examples and findings from the field.
In the meantime, if you have a specific question, reach out. We can talk shop or schedule a lunch and learn for your team. I approach this work with the heart of a teacher, whether I’m talking to technical staff or business leadership.