In 2011 this site ran a short series of posts on the CISSP and the organisation behind it. The earliest of the three, Certifications Do Not Necessarily Make You a Security Professional, set the frame. Why I Lost All Respect for ISC2 made the structural argument: the credential exists primarily as a recurring-revenue product, and the exam content tests the candidate’s ability to memorise a Common Body of Knowledge document rather than the candidate’s ability to defend a network. Hey ISC2, Where is the Opt Out Button closed the trilogy with a specific privacy complaint about the public member directory.

Fifteen years is enough time to ask whether the analysis held. This post is an editorial revisit, not a continuation of authorship. The 2011 commentary on this site predicted a set of outcomes for the certification market. Most of those predictions were confirmed by the path the organisation actually took.

What the 2011 coverage predicted

Three claims were made in that 2011 series, in approximately these words:

1. The CISSP is functionally a paid affiliation with the security industry’s hiring pipeline. The exam content is a barrier-to-entry mechanism, not a competency assessment.
2. ISC2’s governance is designed to make membership-level accountability theoretical rather than operational. The membership cannot effectively recall the board, change the fee structure, or alter the CBK process.
3. The continuing-education programme exists to convert a one-time exam fee into a perpetual revenue stream, with limited apparent connection to maintaining actual defensive competence in the field.

None of those three claims required defending in 2011. The 2011 critique was: someone should defend them, because the credential’s market share will keep growing on the strength of the hiring-pipeline lock-in, not on the strength of the underlying assessment.

What actually happened

The credential market grew. ISC2’s own published material places the certified-membership base at well over half a million worldwide. The CISSP exam fee, US$549 in 2011, has been raised in steps to the current published figure. Annual maintenance fees, US$85 in 2011, are now US$135 for the CISSP-tier credentials and a smaller figure for the entry-level credential the organisation introduced under the “CC” name during the 2022-2023 rebrand. None of those changes are surprising. All of them were on the trajectory the 2011 commentary projected.

The credential portfolio expanded. ISC2 in 2011 offered the CISSP, the SSCP, and the early-stage CSSLP and CAP credentials. In 2026 the same organisation also issues the CCSP (cloud), the HCISPP (healthcare), the ISSAP / ISSEP / ISSMP concentrations on top of the CISSP base, and the entry-level CC introduced under the rebrand. Each of these is a separately-priced credential with its own continuing-education obligation. The expansion is not by itself evidence of bad faith. It is also not evidence of any of the credentials being a stronger competency assessment than the original CISSP. They are additional products in a product line.

The organisation’s published governance structure remains, in operational terms, what it was. The board is elected, but the candidate slate is curated, the petition route is procedurally onerous, and the membership has no recall mechanism that has been exercised in the credential’s full history. The 2011 prediction was that this would not change. That prediction held.

The continuing-education programme grew into the third-party industry the 2011 critique foresaw. There is now a marketplace of CPE-generating products, conferences, webinars, and on-demand course catalogues whose primary commercial logic is supplying credits to credential-holders renewing their certifications. Some of the content is good. Most of the content is structurally indistinguishable from the conference circuit it replaced. The CPE total a credential-holder accumulates per year is a function of how much time they spend filling out forms, not how much new defensive capability they acquired.

The CISSP did not become a competency test

The exam content has been refreshed. The CBK is on its current revision. New domains have been added (cloud, supply-chain considerations, modern identity). The exam-delivery mechanism moved to computer-adaptive testing. None of these revisions, taken in isolation, are objectionable.

The structural critique from 2011 does not turn on the exam being out-of-date in any specific year. It turns on whether the exam content has a measurable correlation with the candidate’s ability to do the work the credential is widely treated as evidence for. There has been no public ISC2-funded study, in fifteen years, demonstrating such a correlation. There has also been no independent peer-reviewed study demonstrating one. The industry has continued to treat the credential as if such a correlation existed, because the hiring market needs a filter and a filter that is widely held is more useful than a filter that is well-validated.

A credential whose primary function is being a widely-held hiring filter is a membership badge. That is the 2011 argument, restated in 2026 terms. The argument has not been refuted; it has been confirmed by the operational behaviour of every actor in the system.

The privacy complaint, briefly revisited

The 2011 post on the member directory remains a useful artefact in 2026 because it shows the credential body could not, in 2011, follow the privacy principles its own credential tested candidates on. The current directory configuration has changed in detail. The structural issue has not. The credential body still publishes member-status information by default; opting out remains a non-trivial process; the membership has not collectively pushed for a stronger default.

The 2011 prediction here was modest: that the privacy treatment would change in small ways but the default posture would not. That prediction held.

What the 2011 coverage missed

Two things, in the interest of being honest about a fifteen-year retrospective.

First, the workforce-gap discourse. ISC2 has, throughout the 2010s and 2020s, published a recurring workforce study reporting a multi-million-position cybersecurity workforce gap. The 2011 critique did not anticipate how durably that framing would justify continued credential growth. The argument “we need more credential-holders because there is a workforce gap” became, over fifteen years, the dominant framing for the credential body’s expansion. The framing has been criticised in adjacent literature for selection-bias issues and definitional looseness. It has nonetheless been load-bearing for ISC2’s institutional growth in a way the 2011 commentary did not foresee.

Second, the speed of competing-credential commodification. By 2026, vendor-specific certifications (AWS, Microsoft, the major cloud-security catalogues) and offensive-security certifications (OSCP and its successors, the CRTO line, the various adversary-emulation credentials) have absorbed a large share of the hiring-filter function that CISSP held a near-monopoly on in 2011. The CISSP is now one credential among several rather than the unambiguous default for senior security roles. The 2011 commentary expected this to happen over a longer timeline than it actually did. Whether that is good or bad for defenders depends on whether the competing credentials are themselves competency tests or whether the hiring market is now filtering on multiple membership badges instead of one. The evidence is mixed.

Closing

The 2011 series argued, in a sharper tone, that the CISSP was a membership fee dressed as a competency test. Fifteen years later, the operational evidence supports the argument and the credential body’s published positioning is, if anything, more candid about treating the credential as a community-membership marker than it was in 2011. The credential is what it was claimed to be. The industry is what it was claimed to be. The hiring-pipeline lock-in is what it was claimed to be.

None of that obligates a working defender to hold the credential, decline to hold the credential, or have any particular opinion about people who hold or do not hold it. It is a paid affiliation with a professional body. That is what it has always been. The 2011 critique on this site was that the rest of the industry should be honest about it. Fifteen years on, parts of the industry have become honest about it. ISC2 has not. The 2011 prediction here was that ISC2 would not, because there is no operational pressure on ISC2 to do so.

That prediction also held.

The NinjaTel team distributed custom Android phones to select attendees. These phones were connected to their own private cellular network running inside the conference venue. The phones came pre-loaded with custom firmware and the whole setup was designed as both a social experiment and a technical demonstration.

From a technical perspective, setting up a private GSM network at a hacker conference is both brilliant and terrifying. It demonstrated just how accessible the technology for running a cellular network has become, and by extension, how vulnerable cellular communications can be.

The implications for security are significant. If a small team can set up a convincing mobile network at a conference, imagine what a well-resourced adversary could do. Rogue base stations, IMSI catchers, and man-in-the-middle attacks on cellular traffic are not theoretical – they are practical and increasingly affordable.

DEFCON continues to be the place where the security community pushes boundaries and demonstrates what is possible. NinjaTel was one of the highlights of this year.

Controversial opinion: traditional security-awareness training for employees is largely a waste of time and money.

Before the pitchforks come out, the position is not that employees should be ignorant about security. The position is that the way most organisations approach security training is fundamentally flawed.

The typical approach: once a year, force everyone through a PowerPoint presentation or online module. Check the compliance box. Move on. Then act surprised when someone clicks a phishing link the next day.

The problem is not the employees. The problem is the design. Asking humans to be perfect security sensors in an environment where the attacks are specifically engineered to exploit human psychology is not a training problem — it is a design problem.

Instead of spending millions on awareness training, invest in:

• Better email filtering and sandboxing
• Removing admin rights from end users
• Application whitelisting
• Network segmentation
• Automated patch management

Design the systems so that when — not if — an employee makes a mistake, the blast radius is contained. That is a much better investment than another round of “don’t click suspicious links” training.

Here is the breakdown of all 8 CISSP domains. I am going to tell you what each one is actually about, what trips people up, and where to focus your study time.

Domain 1: Security and Risk Management

This is the foundation domain and it is the biggest chunk of the exam. It covers security governance, compliance, legal and regulatory issues, professional ethics, and risk management frameworks.

The core concept is understanding how organizations make decisions about risk. You need to know the difference between risk avoidance, risk mitigation, risk transference, and risk acceptance – and when each is appropriate. You also need to understand quantitative risk analysis (ALE = ARO x SLE) and qualitative risk analysis (high/medium/low matrices).

Business continuity planning starts here too. Know BIA (Business Impact Analysis), RPO, RTO, and MTD. Know the difference between a disaster recovery plan and a business continuity plan.

Study tip: Do not just memorize formulas. Understand why an organization would choose one risk response over another. The exam tests judgment, not recall.

Domain 2: Asset Security

Asset security covers data classification, ownership, privacy protection, data retention, and secure handling of information throughout its lifecycle.

The key concepts are data classification levels (government: Top Secret, Secret, Confidential, Unclassified; private sector: Confidential, Private, Sensitive, Public) and the roles of data owner, data custodian, and data steward. The data owner is a senior manager who determines the classification. The custodian implements the security controls. Do not confuse these.

Data remanence is a favorite exam topic. Know the difference between clearing, purging, and destroying storage media. Know that overwriting is clearing, degaussing is purging, and physical destruction is destruction. Know that SSDs require different sanitization than spinning disks because of wear leveling.

Domain 3: Security Architecture and Engineering

This domain covers security models, evaluation criteria, cryptography fundamentals, and physical security. It is the most technically dense domain.

You need to know the formal security models: Bell-LaPadula (confidentiality – no read up, no write down), Biba (integrity – no read down, no write up), Clark-Wilson (integrity through well-formed transactions and separation of duties), and Brewer-Nash (Chinese Wall – prevents conflicts of interest).

Cryptography is heavily tested. Understand symmetric vs. asymmetric encryption, know the common algorithms (AES, RSA, ECC, Diffie-Hellman), understand hashing (SHA-256, SHA-3), and know how digital signatures work (hash then encrypt with private key). Know the difference between block ciphers and stream ciphers, and understand cipher modes (ECB, CBC, CTR, GCM).

Study tip: If cryptography is not your background, spend extra time here. You cannot fake your way through the crypto questions.

Domain 4: Communication and Network Security

Network security covers the OSI model, TCP/IP, network protocols, network attacks, and secure network design. If you have a networking background, this domain will feel comfortable. If you do not, it requires serious study.

Know the OSI model cold – not just the layer names but what protocols operate at each layer and what security controls apply. Know TCP/IP thoroughly: the three-way handshake, how DNS works, how ARP works, and how each can be attacked.

Understand network segmentation, VLANs, firewalls (stateless vs. stateful vs. application layer), IDS/IPS (signature-based vs. anomaly-based), and VPN technologies (IPsec, SSL/TLS). Know the difference between transport mode and tunnel mode in IPsec.

Wireless security is tested: know WEP (broken), WPA (better but has weaknesses), WPA2 (current standard using AES-CCMP), and WPA3 (latest). Know the attacks against each.

Domain 5: Identity and Access Management (IAM)

IAM covers identification, authentication, authorization, and accountability. This is where you learn about access control models and authentication mechanisms.

Know the access control models: DAC (discretionary – owner sets permissions), MAC (mandatory – system enforces labels), RBAC (role-based – access based on job function), and ABAC (attribute-based – access based on attributes of subject, object, and environment).

Authentication factors: something you know (password), something you have (smart card, token), something you are (biometrics). Multi-factor means two or more different categories. Two passwords is not multi-factor.

Understand single sign-on (SSO) technologies: Kerberos (know the ticket-granting process), SAML, OAuth, and OpenID Connect. Know federated identity management and how trust relationships work between organizations.

Study tip: Kerberos questions are almost guaranteed. Know the components (KDC, TGT, service ticket) and the authentication flow.

Domain 6: Security Assessment and Testing

This domain covers vulnerability assessments, penetration testing, security audits, and software testing techniques.

Know the difference between a vulnerability assessment (identify weaknesses) and a penetration test (attempt exploitation). Know the types of penetration tests: black box (no prior knowledge), white box (full knowledge), and gray box (partial knowledge).

Understand log reviews, code reviews, and security metrics. Know the OWASP Top 10 web application vulnerabilities. Understand static analysis (SAST) and dynamic analysis (DAST) for application security testing.

SOC 1, SOC 2, and SOC 3 reports come up here. SOC 1 is about financial controls. SOC 2 is about security, availability, processing integrity, confidentiality, and privacy – it is the one security professionals care about. Type I is a point-in-time assessment; Type II covers a period of time (usually 6-12 months).

Domain 7: Security Operations

Security operations covers incident management, disaster recovery, physical security operations, change management, and forensics.

Incident response phases: preparation, detection/analysis, containment, eradication, recovery, lessons learned. Know this sequence. Know the difference between containment strategies (short-term containment like isolating a system vs. long-term containment like patching while maintaining evidence).

Digital forensics principles: order of volatility (collect most volatile evidence first – registers, cache, RAM, disk, remote logs), chain of custody, evidence integrity (hashing), and the difference between a forensic image and a backup.

Disaster recovery is tested heavily. Know hot sites (fully operational, switchover in hours), warm sites (partially equipped, days to activate), cold sites (empty facility, weeks to activate). Know RAID levels and their trade-offs. Know backup types: full, incremental (backs up changes since last backup of any type), and differential (backs up changes since last full backup).

Study tip: The incident response and DR questions are scenario-based. Practice applying the frameworks to specific situations rather than just memorizing steps.

Domain 8: Software Development Security

This domain covers secure software development practices, application vulnerabilities, and database security.

Know the SDLC phases and where security activities fit in each phase. Know common application vulnerabilities: buffer overflows, SQL injection, cross-site scripting, cross-site request forgery. Know the OWASP Top 10.

Understand database security concepts: inference attacks, aggregation attacks, polyinstantiation, views for access control. Know the difference between relational databases, object-oriented databases, and NoSQL databases from a security perspective.

Software development models: Waterfall, Agile, Spiral, DevOps/DevSecOps. Know where security testing fits in each model. Know what a maturity model is (CMM/CMMI levels).

Study tip: This domain has a lot of overlap with Domain 3 (security models) and Domain 6 (testing). If you study those well, Domain 8 will feel manageable.

How to Actually Pass

The CISSP is not a technical exam. It is a management and decision-making exam that requires technical knowledge. The questions test whether you can think like a security manager, not whether you can configure a firewall.

Read one primary source (the official study guide or Shon Harris) and one secondary source (practice exams, video courses). Do at least 1,000 practice questions. Review every wrong answer until you understand why the “correct” answer is correct from ISC2’s perspective, even if you disagree.

The exam is adaptive now. You get 100-150 questions in 3 hours. Do not panic if the questions seem hard – that means the adaptive engine thinks you are doing well.

Good luck. The CISSP is worth having, despite everything I have said about ISC2 over the years.

MSSP: Managed Security Service Provider

An MSSP is a company that provides outsourced monitoring and management of security devices and systems. Think of it as hiring a team of security analysts to watch your network 24/7 so you do not have to build that capability in-house.

What an MSSP typically offers

• 24/7 security monitoring – A Security Operations Center (SOC) that watches your logs, alerts, and events around the clock
• Firewall and IDS/IPS management – They configure, monitor, and maintain your security devices
• Vulnerability scanning – Regular scans of your infrastructure to identify weaknesses
• Log management and SIEM – Collecting, correlating, and analyzing security logs from across your environment
• Incident response support – When something bad happens, they help you deal with it
• Compliance reporting – Generating the reports your auditors want to see

MSSP vs MSP

Do not confuse an MSSP with an MSP (Managed Service Provider). An MSP manages your IT infrastructure – servers, networks, help desk. An MSSP focuses specifically on security. Some companies do both, but the skill sets are very different. Your MSP keeping your Exchange server running is not the same as detecting a sophisticated intrusion.

When does an MSSP make sense?

For small and mid-size organizations that cannot justify the cost of a full in-house security team, an MSSP is often the most practical option. Building a 24/7 SOC requires a minimum of 5-6 analysts plus management, tools, and infrastructure. That is a significant investment. An MSSP spreads that cost across many clients.

Larger organizations may use an MSSP to supplement their internal team or to cover off-hours monitoring.

The catch

Not all MSSPs are created equal. Some are just forwarding vendor alerts with no real analysis. Ask about their analyst-to-client ratio, their mean time to detect and respond, and whether they do actual threat hunting or just react to alerts. A bad MSSP gives you a false sense of security, which is worse than no MSSP at all.

Do your homework before signing a contract.

AntiSec went after law enforcement that weekend. Hard.

Over 70 law-enforcement websites were compromised in what they called “Shoot the Sheriff Saturday”. The data dump included personal information on approximately 7,000 law-enforcement officers — names, addresses, phone numbers, Social Security numbers, and passwords.

To be clear before going any further: this is not an endorsement. Leaking SSNs and personal addresses of police officers puts real people and their families at risk. Whatever the politics, that is a line.

The scope

The targets were mostly small to mid-size police department websites. County sheriff offices, municipal police departments, a few state-level law-enforcement sites. The kind of sites that were probably built by the lowest bidder fifteen years earlier and never updated.

The passwords in the dump are illuminating. The usual suspects: “password123”, “police1”, badge numbers, first names followed by birth years. These are the people responsible for protecting communities, and they cannot protect their own accounts.

The political context

AntiSec framed the dump as retaliation for the arrests of Anonymous and LulzSec members. The accompanying statement referenced specific cases — the PayPal 14, Topiary, and others. The message was clear: arrest our people, we come after yours.

This is escalation. And escalation in this space does not end well for anyone.

What this tells us about the state of web security

The fact that 70+ government websites could be compromised in what appears to be a single coordinated operation tells the industry everything it needs to know about the state of government web security. SQL-injection attacks against unpatched CMS installations. Default credentials left in place for years. Databases with plaintext passwords.

This is not sophisticated. This is negligence. And it is negligence at every level — the departments that never funded security, the IT staff who never patched, the vendors who delivered insecure products and walked away, and the oversight bodies that never audited any of it.

Seventy websites. One weekend. By a group of activists with freely available tools.

Think about what a nation-state could do.

The criticism levelled at ISC2 in earlier coverage on this site continues to apply, with a new issue worth flagging: the member directory.

ISC2 has made CISSP-holder information searchable online. Name, certification status, and other details are available for anyone to look up. The problem: there is no clear way to opt out of having that information publicly listed.

For an organisation that is supposed to represent information-security professionals, this is embarrassing. Security professionals spend their careers telling organisations to minimise data exposure, implement privacy controls, and give users control over their personal information. Yet the organisation that certifies them cannot follow its own principles.

Privacy is not just a technical issue. It is a fundamental right. Security professionals, of all people, should not have their information exposed without explicit consent and without a clear mechanism to withdraw that consent.

ISC2: add an opt-out button. It should not be this hard.

Happy Fourth of July. Someone compromised the @FoxNewsPolitics Twitter account overnight and posted a series of tweets claiming President Obama had been shot and killed. The tweets stayed up for hours.

Let that sink in for a moment. A verified news-organisation Twitter account was used to broadcast a fake presidential assassination to over 30,000 followers. On Independence Day.

What happened

The tweets appeared between 2:00 and 6:00 AM Eastern. They claimed Obama had been shot at a Ross restaurant in Iowa, provided fake details about wounds and hospital status, and even announced a fake death. The account was not recovered until morning.

The group claiming responsibility called themselves The Script Kiddies, allegedly affiliated with Anonymous. Whether that affiliation was real or self-declared was anyone’s guess. In the current climate, everyone wants to be associated with Anonymous.

The real problem here

This is not about Fox News getting embarrassed. This is about the credibility infrastructure of social media as a news-distribution platform.

Twitter has become a primary news source for millions of people. When a verified account belonging to a major news network broadcasts a presidential assassination, people believe it. Some of those people act on it. Markets could move. Panic could spread. People could get hurt.

The security protecting that verified account? A password. That is it. A single password standing between a Twitter account and a national panic.

Lessons nobody will learn

1. Every corporate social-media account needs multi-factor authentication. This was true before today and it will still be true tomorrow when everyone forgets about this.
2. Social-media credentials should not be shared among teams via email or spreadsheet. They are shared via email or spreadsheet at virtually every organisation that does not actively police it.
3. Incident-response plans need to include social-media compromise scenarios. Almost none do.
4. The speed at which false information spreads on Twitter makes traditional “contact our PR team” response times dangerously inadequate.

Nobody will implement any of these recommendations. The industry will have this exact same conversation again within the year, with a different account and a different fake crisis.

The original piece on what the CISSP does not teach was framed as part one of an ongoing series. This is part two. As before, the certification is not being picked on because it is worthless; it is being picked on because it is treated as proof of operational competence and it is not. The exam has its place, but if the first move when something breaks at an organisation is to pull out the AIO study guide, the organisation is in trouble.

Threat modelling that does not survive contact

The CISSP teaches threat modelling as an exercise. STRIDE. DREAD. Attack trees. The acronyms get learned, a couple of textbook examples on a fictional banking application get worked through, and then the curriculum moves on. It is a lovely framework with its uses. The problem is that real threat models in real companies are political documents long before they are technical ones.

Here is what actually happens. A workshop convenes with the team that owns the system. Someone starts asking who the threat actors are and what they want. The product owner says “all of them”. The developer says “nation states” because it sounds impressive. The compliance person says “auditors”. The CISO has already mentally selected the threat model that justifies the project they want funded next quarter. By the time the workshop ends, the document everyone signed off on addresses none of the actual threats anyone would face.

What the CISSP does not teach is how to keep a threat-modelling exercise honest. The trick is to start with the assets, not the threats, and to force the room to rank them in front of each other. Once everyone has publicly agreed that the customer database matters more than the public marketing brochure site, the threat model writes itself, because the controls follow the rankings. If the ranking exercise gets political, that is the actual threat — and it has just been identified.

Risk acceptance as a cultural problem, not a process

The CISSP curriculum spends a lot of time on the risk-acceptance process. There is a form. Someone signs the form. The risk is now accepted. Done.

What actually happens in real organisations is this. The form goes around. Nobody who is busy reads it. The person who signs it is usually the person who is least exposed to the operational consequences. Six months later, the thing that everyone politely declined to address goes wrong, and the post-incident review concludes that the original risk acceptance was made without enough information.

The CISSP does not teach that the risk-acceptance process is theatre. It teaches that the risk-acceptance process is a control. The job of security leadership inside an organisation is to recognise when an acceptance is being signed by someone who is not actually accountable, and to escalate. That is a culture skill, not a process skill, and the certification has nothing to say about it.

Vendor management is a security function, not a procurement function

This is where the CISSP fails the modern practitioner the most. There is a domain called “Security Operations” but the level of attention paid to vendor and third-party risk is roughly proportional to how it was understood in 2003. The reality is that most organisations have more of their critical data sitting at vendors than they do on their own infrastructure. SaaS, IaaS, MSP managed databases, payroll providers, marketing automation.

The CISSP will tell candidates to put security clauses in the contract. Fine. Anyone who has ever pulled a vendor contract after a breach and tried to actually enforce a security clause knows it is a long, uphill, expensive fight, and the contract is the wrong place for the control. The right place is the architecture decision that picks the vendor in the first place, and the ongoing assurance work that confirms they are doing what they said they would do. None of which is in the curriculum.

Detection engineering does not exist in the curriculum

The CISSP has things to say about logging, monitoring, IDS, and SIEM. What it does not have is anything resembling modern detection engineering. The discipline of writing detections, testing them against real adversary behaviour, retiring the ones that produce nothing, and treating the detection corpus as production code is something the certification has not caught up to.

Candidates coming out of the CISSP thinking that “implement an IDS” is a control end up sitting in front of SIEMs that fire forty thousand low-confidence alerts a day, none of which anyone is investigating, and calling that “monitoring”. The CISSP does not tell them that ninety percent of those alerts should be deleted, that the remaining ten percent should be tuned, and that what is actually needed is a small number of high-confidence detections written against the specific environment.

The escalation question

The CISSP teaches the org chart. Who reports to whom, the right escalation path for an incident, and so on. Clean. Boxes and lines.

What the CISSP does not teach is that the most important escalation skill a security leader will ever develop is knowing when to go around the org chart, and how to do it without becoming the person who gets fired the next month for being political. There are situations in every organisation where the right call is to walk past your manager and into someone else’s office. Doing this wrong is career-ending. Doing it right is sometimes the only thing that saves the organisation from a real, public, expensive failure.

The certification cannot teach this. A mentor who has been through it twice and is willing to share what they learned can teach this. That mentor is worth more than the next three certifications anyone is tempted to chase.

Closing

This series will continue. The next instalment will probably be about audit fatigue, why most security audits produce reports that nobody reads, and what to actually do when an auditor flags something that is not the real risk. Not because audits are useless, but because the certification trains candidates to satisfy auditors rather than to lead a security program.

How do we celebrate at JadedSecurity??? Well we shout out to our friends! ISC2, Proudly killing kittens since 1988