Security work asks two things of a person before any framework or certificate enters the picture. They have to know enough to see when a system or a process creates risk, and they have to care enough to act on it. If either is missing, obvious safeguards turn into optional suggestions. I said this recently in a much blunter form: that most people lack the moral compass, common sense and ethics the work needs, and that frameworks exist to constrain everyone who lacks them. The core of that I still hold. Competence, character and responsibility are prerequisites for this work, and a checklist doesn’t replace them. Some of the broader claims around that core, though, were judgments no dataset can confirm, and a few go further than the measurements do. So this is the longer version, built on what the evidence actually supports.

Two different failures

There are two separate ways a person fails at security, and they shouldn’t be confused.

The first is a lack of competence. The person doesn’t know the rule, doesn’t understand why it exists, or can’t recognize that what they’re doing is dangerous. A developer who thinks Base64 protects a password isn’t choosing to put anyone at risk. They can’t see the risk. That’s ignorance, and ignorance isn’t malice.

The second is knowing disregard. The person understands the safeguard and sets it aside anyway: to save time, to keep working, because it’s someone else’s problem. It isn’t necessarily malice either. But it’s a different failure from ignorance, because the knowledge was there and the judgment went the other way.

Both lead to the same place in practice, which is a safeguard that exists on paper and not in the system. That’s why it’s tempting to lump them together. They need to stay apart, because the evidence on each looks very different, and because a gap in knowledge shouldn’t be read as a defect of character.

What the knowledge gap looks like

Start with the general population, because that’s where my original claim was loosest. I wrote that the average person has near-zero computer literacy. The measured numbers don’t say that. In the OECD’s 2023 Survey of Adult Skills, covering adults aged 16 to 65 across 31 countries and economies, 29% scored at Level 1 or below in adaptive problem solving, and only 5% reached the top level. The most common result was Level 2, at 38.5%. That test measures general problem solving in changing situations, not computer or security skill. Eurostat’s digital skills indicator is closer to computer use, but it’s built from self-reported activities rather than tested ability. By that measure, 60.4% of EU residents aged 16 to 74 had at least basic overall digital skills in 2025, which leaves roughly four in ten below basic. In Slovenia the figure was 46.5%.

So the accurate statement is narrower. On the OECD’s general problem-solving measure, a large minority of adults scores at Level 1 or below, most score at Level 2 or 3, and only 5% reach Level 4. On Eurostat’s self-reported proxy, about four in ten EU residents fall below basic digital skills. That’s a real problem for anyone designing systems those people will use. It isn’t “near zero” for the average person. And none of it says anything about people who work in IT. Those figures describe the general public, and the people who build and run systems are counted inside them without being measured separately.

For practitioners, the useful evidence comes from studies that examined the work itself or asked practitioners about it directly. Three stand out, and each has a narrow sample that matters for how far it can be read.

In 2019, Naiakshina and colleagues hired 43 Java freelancers through Freelancer.com to build a user registration feature for what looked like a real client project. The freelancers had been randomly assigned to conditions before the job offer went out, and those who accepted made up the sample. Some of the task descriptions asked explicitly for secure password storage. The rest didn’t mention it. Without the prompt, 4 of 21 delivered secure storage. With it, 13 of 21 did. Several used Base64 encoding as their idea of protection, and the authors found that encryption and hashing were used as synonyms. They also wrote that “a number of freelancers did not feel responsible for security.” Forty-three freelancers paid €100 or €200 for a Java task is a small, specific group, and the result can’t be stretched to developers as a whole. Within that group, the difference between prompted and unprompted work is an experimental result.

Votipka and colleagues looked at 94 projects from Build It, Break It, Fix It, a secure-programming contest, and the 866 exploits other teams submitted against them. About three quarters of the teams entered as the capstone to an online security course sequence. The authors note that most participants were also post-degree professionals, with an average of 8.9 years of software development experience. In 78% of projects, teams introduced at least one vulnerability that came from misunderstanding a security concept. In 21%, they made at least one simple coding mistake. Those two figures describe projects, can overlap, and don’t add up to anything. They come from a contest, not a random draw of working engineers. What they show is that, in this contest, conceptual security errors turned up in far more projects than simple coding slips did.

Dietrich and colleagues surveyed system operators in 2018. Of 221 respondents, 170 (76.92%) said they had misconfigured a system, and 68 (30.8%) said at least one misconfiguration had led to a security incident. Asked which factors contributed to the misconfigurations they had encountered, respondents most often selected lack of knowledge (78.73%) and lack of experience (75.57%). They selected sole responsibility (76.92%) and insufficient quality assurance (73.30%) almost as often. The respondents were recruited through operator communities and weren’t paid, so this is a self-selected group reporting on itself, not a workforce survey.

Put together, these studies show something narrower than “most IT workers are unfit for their roles,” and I can’t claim the broader version. The research reviewed here provides no representative, performance-based test of IT workers that could confirm or refute it. What the studies do show is that in each of these groups, a substantial share of people who were paid, or trained, to build or run systems got basic security wrong in the work examined, or reported having done so. That’s enough for my point. Storing a password with Base64, or confusing hashing with encryption, isn’t a subtle mistake in someone who has taken the job of handling other people’s credentials. Knowing the difference is part of the job, and taking the job without it is a responsibility problem as well as a knowledge one.

The freelancer study has one more result worth stating exactly. In the first submissions, 17 solutions were secure (4 of 21 unprompted, 13 of 21 prompted). Freelancers who had handed in insecure solutions were then sent a request to add security, and after that the authors report that 29 freelancers overall stored passwords securely. That rise says nothing about what anyone knew beforehand, since people can look things up once asked, and aggregate counts don’t track individuals. What the study does show is that, in this group, secure storage was far more common when someone explicitly asked for it.

What knowing disregard looks like

Knowing disregard is harder to measure, because the record of a breach rarely says whether the person knew the rule.

The best large source is Verizon’s 2026 Data Breach Investigations Report, which covers 22,624 breaches from incidents between November 2024 and October 2025. Verizon counts a “non-intentional human element” in 62% of those breaches: someone clicked, made a mistake, or was manipulated. The pattern it calls Privilege Misuse, meaning intentional misuse of access by insiders, accounts for just under 4% of breaches. In those misuse breaches, the most common motive was convenience, at 60%. The report’s example is an employee who emails company data to a personal account to keep working from home. In Verizon’s words, that person “wasn’t specifically acting with malicious intent,” but “clearly violated the data-handling policies of their employer and caused a data breach.” The report also says that “your own people are typically much more likely to lose an asset or make a mistake than to intentionally abuse their access.”

That data needs careful handling. The denominator is breaches, not people, so neither 62% nor 4% says what fraction of workers make mistakes or break rules on purpose. Verizon itself states that the sample isn’t representative of all breaches and only includes organizations that were breached, detected it and reported it. “Non-intentional” doesn’t mean the person didn’t know better, either. A mistake can come from ignorance, overload or carelessness, and no large dataset separates “didn’t know the rule” from “knew it and ignored it.” So the breach data doesn’t show that knowing disregard is absent. It shows that among the breaches in Verizon’s dataset, deliberate insider misuse was a small share, and that within it, the typical case was convenience rather than malice.

The convenience example is the closest the breach data comes to knowing disregard. The documented behavior is that an employee moved company data to a personal account, against the employer’s data-handling policy, in order to keep working. Verizon codes the motive as convenience, not malice. The coding doesn’t say how well the employee understood the risk. The breach was real either way.

Research inside organizations gives the reasons behind choices like that, and they’re mostly about friction. Beautement, Sasse and Wonham interviewed 17 employees at two organizations and found that the decision to comply depends on the actual and anticipated costs and benefits to the individual, which they called the compliance budget. Kirlappos, Parkin and Sasse analyzed 118 interviews at a large multinational and described “shadow security”: cases where “security-conscious employees who think they cannot comply with the prescribed security policy create a more fitting alternative.” In hospitals, Koppel and colleagues “observed entire hospital units share a password to a medical device, where the password is taped onto the device.” These are qualitative studies of particular workplaces. They show how rule-breaking happens, not how common it is.

This evidence cuts against reading every workaround as callousness. Some of the people bending rules are the ones who care about security, working around a control that doesn’t fit the job. Convenience, workload and friction don’t prove that someone is indifferent to risk. But the same evidence doesn’t erase responsibility. Clinicians sharing a password taped to a medical device and an employee emailing company data to a personal account to keep working from home both bypassed a control or broke a policy, and the circumstances behind those actions aren’t the same. Where someone does knowingly set a safeguard aside, that’s still a choice, and the person who made it still owns the risk it created, even when the choice is understandable.

What frameworks can do

My original post said that self-evident rules must become formal frameworks because people can’t be trusted, and that frameworks exist to constrain the rest. I can’t show why every framework was written. The sources say what particular frameworks require and how they perform, not what motivated all of them. What the evidence can address is whether they work.

Frameworks can enforce rules, and when the controls they require actually operate, the effect is measurable. Gandal, Moore, Riordan and Barnir used a mandatory Israeli government survey of firms from 2020 and 2021. Of 993 firms that knew about the national cyber directorate’s directives, 384 (39%) said they had fully implemented them. Firms that had suffered incidents tended to add controls afterwards, so a simple comparison makes security controls look associated with more incidents. The authors used implementation of the directives as an instrumental variable to separate those effects. They found that “employing more security precautions indeed reduces the probability of suffering a cyber incident.” In their model, for the riskiest group of large firms, adopting six basic precautions (among them keeping systems updated, two-factor authentication and malware detection) cut the estimated probability of an incident from 80% to 42%. This is one country and self-reported incidents. The result depends on the authors’ assumptions about their instrument, which they interpret as a sign of a firm’s vigilance. It’s about controls in operation, not certificates on a wall.

Payment-card data points the same way, with its own bias. Verizon’s 2015 PCI Compliance Report states that across ten years of its forensic breach investigations, “not a single company has been found to be compliant at the time of the breach.” Its unbreached comparison group outperformed breached companies by 36 percentage points on average across the standard’s requirements. The same report notes that post-breach investigators look for non-compliance rather than validating compliance, which pushes the numbers in this direction. It’s also the clearest source on what an assessment can’t prove: “a compliance assessment can only ever be a snapshot. All it in fact proves is that the company was able to demonstrate compliance at that moment, for the selected sample of sites, devices and systems checked.” Less than a third (28.6%) of companies were still fully compliant less than a year after successful validation. Verizon also separates companies whose goal is to comply, “teaching to the test,” from those focused on security.

That distinction between a control that operates and a requirement that was once demonstrated is where the documented failures happen.

Target’s chief financial officer told a Senate committee that the company had been certified in September 2013 as compliant with the payment card industry standard. The Senate Commerce Committee majority staff’s analysis, based on what had been publicly reported, lists among the missed opportunities that Target “appears to have failed to respond to multiple automated warnings” from its anti-intrusion software.

At Equifax, the written rule existed and was communicated. The House Oversight Committee majority staff found that after a critical Apache Struts vulnerability was disclosed in March 2017, the security team emailed an alert to over 400 people instructing anyone running Apache Struts to patch within 48 hours. The consumer dispute portal that attackers later used was not patched. Separately, the device that monitored traffic from that portal wasn’t working because of an expired security certificate, so the exfiltration went unseen. The company had let over 300 security certificates expire. The report describes “a lack of accountability and no clear lines of authority in Equifax’s IT management structure,” leading to “an execution gap between IT policy development and operation,” and calls the breach “entirely preventable.”

The Cyber Safety Review Board’s 2024 review of the 2023 Microsoft Exchange Online intrusion found it “was preventable and should never have occurred.” Attackers forged authentication tokens with a consumer signing key Microsoft had created in 2016. Microsoft had stopped rotating consumer signing keys manually in 2021 after an outage, had not built automated rotation for that system, and had no alerting on the age of active keys. The Board concluded that “Microsoft’s security culture was inadequate and requires an overhaul,” citing “the cascade of Microsoft’s avoidable errors.” It also found that “existing compliance requirements for government cybersecurity do not consistently require sound practices around key management or token issuance.”

These cases don’t show that frameworks are useless, and they don’t show that anyone involved was unethical. The investigators attribute the failures to governance, accountability, prioritization and culture. What they show is the gap I care about. A rule can be written, sent to 400 people and still not be carried out. An organization can pass an assessment and still miss the warnings in front of it. And a framework only constrains what it requires. Where its requirements stop, good practice depends on whether someone with the competence to see the risk and the responsibility to act on it is there.

What a certificate shows

Frameworks can enforce rules, but completing a certification doesn’t prove competence, character or sound judgment. That needs stating carefully, because “a certificate proves nothing” is also wrong. A certificate is evidence that someone completed a defined set of requirements. Whether those requirements say anything about skill depends on what they are.

Individual credentials and organizational certifications are different things. The CISSP, for example, requires a minimum of five years of cumulative, full-time experience in two or more of eight domains, and an adaptive exam of 100 to 150 items over three hours with a pass mark of 700 out of 1000. Passing shows performance on a knowledge exam across those domains, plus the required experience. It isn’t a test of performance in a live environment.

Hands-on credentials carry more signal about skill. A study by Chen and colleagues, published at HCII 2026, screened 269 candidates for a two-day cyber-range hacking experiment and ended with 61 participants. The 25 holders of the OSCP, whose exam is 23 hours and 45 minutes of practical attack work, progressed significantly further than the 36 non-holders (p = 0.002). A separate skills test added 5.2% of explained variance beyond certification. The authors list the limits themselves: the score didn’t capture stealth or efficiency, the setting was one platform, and certificate holders are more likely to work in offensive roles, so the certificate can’t be separated from the experience behind it. So within that one task, a practical credential tracked demonstrated skill. Nothing in the study measured judgment in unfamiliar situations, character, or whether holders’ employers get breached less.

An organizational certification attests something different again. ISO describes conformity with ISO/IEC 27001 as meaning that an organization “has put in place a system to manage risks related to the security of data.” That’s an attestation about a management system. On its own it doesn’t say which specific controls would stop which attacks.

Completed training follows the same logic. Ho and colleagues studied more than 19,500 employees of a US healthcare organization over eight months and ten simulated phishing campaigns. They found “no significant relationship between whether users have recently completed cybersecurity awareness training and their likelihood of failing a phishing simulation.” Randomized embedded training reduced the average failure rate by only about 2%, and over half of embedded training sessions ended within 10 seconds. The annual-training result is observational, and it comes from one organization and one type of simulated attack. But it shows a completed requirement sitting alongside unchanged behavior.

A completed requirement is evidence of exactly what was required and checked. A practical exam can show skill on the kind of task it tests. A knowledge exam can show knowledge. An audit can show what the auditor sampled on the day. None of them measures whether the person will treat a safeguard as binding when no one is checking.

Character

That last point is where my original claim has to change shape. I said most people lack the moral compass and ethics security work needs. No dataset measures moral character across a population, so that statement can’t be confirmed, and I won’t present it as fact. Breach reports code actions and motives after the event. Compliance studies mostly measure what people say they intend. Neither measures whether someone has a conscience.

What doesn’t change is the requirement, and the evidence above shows where it sits. In the freelancer study, secure storage was far more common when someone explicitly asked for it, and the authors reported that a number of freelancers didn’t feel responsible for security. Equifax’s patch instruction reached over 400 people, and investigators described a lack of accountability that left an execution gap between policy and operation. Neither source measures anyone’s character. What I mean by character in this work is treating an obvious safeguard as binding rather than as an optional suggestion, including when it’s inconvenient and nothing outside the person is enforcing it.

Sources

  1. Peter Aleksander Bizjak (@peteralexbizjak), quote post on X, 7 November 2026. https://x.com/peteralexbizjak/status/2119122164121022960
  2. OECD, “Literacy, numeracy and adaptive problem solving among adults in 2023”, chapter 2 of Do Adults Have the Skills They Need to Thrive in a Changing World? Survey of Adult Skills 2023, 10 December 2024. https://www.oecd.org/en/publications/do-adults-have-the-skills-they-need-to-thrive-in-a-changing-world_b263dc5d-en/full-report/literacy-numeracy-and-adaptive-problem-solving-among-adults-in-2023_10f6782f.html
  3. Eurostat, “Skills for the digital age”, Statistics Explained (data extracted January 2026); dataset isoc_sk_dskl_i21. https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Skills_for_the_digital_age
  4. Naiakshina, Danilova, Gerlitz, von Zezschwitz and Smith, “If you want, I can store the encrypted password. A Password-Storage Field Study with Freelance Developers”, CHI 2019. https://doi.org/10.1145/3290605.3300370
  5. Votipka, Fulton, Parker, Hou, Mazurek and Hicks, “Understanding security mistakes developers make: Qualitative analysis from Build It, Break It, Fix It”, 29th USENIX Security Symposium, 2020. https://www.usenix.org/system/files/sec20-votipka-understanding.pdf
  6. Dietrich, Krombholz, Borgolte and Fiebig, “Investigating System Operators’ Perspective on Security Misconfigurations”, ACM CCS 2018. https://kevin.borgolte.me/files/pdf/ccs2018-security-misconfigurations.pdf
  7. Verizon, “2026 Data Breach Investigations Report”, 2026. https://www.verizon.com/business/resources/Tdca/reports/2026-dbir-data-breach-investigations-report.pdf
  8. Beautement, Sasse and Wonham, “The Compliance Budget: Managing Security Behaviour in Organisations”, NSPW 2008. https://discovery.ucl.ac.uk/id/eprint/1301853/1/compliance_budgetfinal.pdf
  9. Kirlappos, Parkin and Sasse, “Learning from ‘Shadow Security’: Why understanding non-compliance provides the basis for effective security”, Workshop on Usable Security (USEC), 2014. https://discovery.ucl.ac.uk/id/eprint/1424472/
  10. Koppel, Smith, Blythe and Kothari, “Workarounds to Computer Access in Healthcare Organizations: You Want My Password or a Dead Patient?”, ITCH 2015 (draft). https://sws.cs.dartmouth.edu/pubs/ksbk15-draft.pdf
  11. Gandal, Moore, Riordan and Barnir, “Empirically Evaluating the Effect of Security Precautions on Cyber Incidents”, Computers & Security 133 (2023), 103380. https://doi.org/10.1016/j.cose.2023.103380
  12. Verizon, “2015 PCI Compliance Report” (copy hosted by Integrity360). https://insights.integrity360.com/hubfs/Integrity360-April2019/pdf/1427815497-verizon_2015_pci_compliance_re_28163.pdf
  13. Majority Staff, U.S. Senate Committee on Commerce, Science, and Transportation, “A ‘Kill Chain’ Analysis of the 2013 Target Data Breach”, 26 March 2014, reproduced in hearing record S. Hrg. 113-531. https://www.govinfo.gov/content/pkg/CHRG-113shrg92594/html/CHRG-113shrg92594.htm
  14. Majority Staff, U.S. House Committee on Oversight and Government Reform, “The Equifax Data Breach”, December 2018. https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf
  15. Cyber Safety Review Board, “Review of the Summer 2023 Microsoft Exchange Online Intrusion”, 20 March 2024. https://www.cisa.gov/sites/default/files/2024-03/CSRB%20Review%20of%20the%20Summer%202023%20MEO%20Intrusion%20Final_508c.pdf
  16. ISC2, “CISSP Certification Exam Outline”, effective 15 April 2024. https://www.isc2.org/-/media/Project/ISC2/Main/Media/documents/exam-outlines/CISSP-Exam-Outline-April-2024-English.pdf
  17. Chen, Oh, Hsing, Lau, Beltz, Wu and Zhu, “Efficiency and Equity in Screening for Participants in Representative Cybersecurity Studies”, HCII 2026 (author proof). https://vtechworks.lib.vt.edu/server/api/core/bitstreams/c8561fe6-40ca-4c88-9fa7-7741fda785d9/content
  18. ISO, “ISO/IEC 27001:2022 Information security management systems”, standard page. https://www.iso.org/standard/27001
  19. Ho, Mirian, Luo, Tong, Lee, Liu, Longhurst, Dameff, Savage and Voelker, “Understanding the Efficacy of Phishing Training in Practice”, IEEE Symposium on Security and Privacy 2025. https://www.sysnet.ucsd.edu/~voelker/pubs/phishtrain-oakland25.pdf