Every safeguard in 0004.b costs something. It may cost users time and patience, deny access to someone who legitimately needs it, collect information about people, slow a system down, or simply cost money and staff hours. Security decisions are therefore choices among goods, and the central tension of this section is between protection and everything that protection takes away. One principle runs through all of these choices: protection should be proportional to risk, which combines the likelihood of a harm with its impact. This section first looks at five things security is traded against, usability, availability, privacy, performance, and cost, and then at three recurring decisions, password policy, patch timing, and the use of outside vendors, in which several of those trade-offs come together.

What security is traded against#

The most visible trade-off is with usability. Stronger security often adds friction: short session timeouts and multifactor authentication protect accounts but inconvenience legitimate users, and users who find a control too burdensome look for workarounds, such as writing passwords on sticky notes or sharing one logged-in account. A control that people bypass can leave systems less secure in practice than a milder one they follow, so the best approach is to examine how people work and then choose controls they can actually follow. Friction should be proportional to the risk. A bank can reasonably log users out faster than a recipe app, and an organization might use simpler sign-in methods for low-risk apps and stronger ones for sensitive systems, since requiring MFA for every trivial task pushes users toward unsafe shortcuts.

A second trade-off lies inside the CIA triad itself, between confidentiality and availability. Tighter restrictions improve confidentiality, but they can block legitimate access, as when a web filter blocks an educational site a teacher needs, or when staff with a genuine need can't reach a student's medical information in time. Controls should fit the sensitivity of the data and the needs of its users, so the right response to an overzealous filter is to review the block and allow the specific site. Some designs preserve both properties. Emergency "break-glass" access lets someone bypass a normal restriction in an urgent situation, while logging each use and reviewing it afterward, which keeps information available and keeps people accountable. Confidentiality pursued without regard to availability can defeat itself: if a single person holds the only key to a company's encrypted files, the files are well protected from outsiders, but the company can't use them either if that person leaves or forgets it.

A third trade-off sets security against privacy, and it can be surprising, since both sound like protection. Detailed monitoring and logging improve threat detection, but they collect more information about the people being monitored. The same data that helps detect an attack on a school network also reveals what students do online, and inspecting all of a company's encrypted traffic makes employees' personal traffic, such as online banking, visible to company systems. The privacy cost can be reduced without giving up detection: collect only what is needed, keep it briefly, limit who can read it, and be transparent, for example by telling families what is monitored and why, so that people understand the trade-off being made on their behalf.

A fourth trade-off is with performance. Encryption, malware scanning, and logging all consume processing and network resources. HTTPS, for example, adds a slightly slower setup to each encrypted connection, before page data begins to flow, in exchange for protection. For sensitive data, small costs like this are usually worth accepting. Where a cost becomes large, tuning a control often preserves most of the protection: scans can skip trusted folders where software is built, with full scans run on a schedule, and logging can record only the events that matter, which keeps most of the value at less cost.

The last of these trade-offs, cost, underlies all the others. Safeguards cost money and staff time, and no organization can afford all of them, so organizations prioritize risks by their combination of likelihood and impact. A staff password known to have been stolen is high on both, since someone is likely to use it and it opens real systems, so it comes before a risk that is unlikely or would do little harm. A safeguard that costs far more than the loss it would prevent isn't worth buying. A safeguard's real cost includes the staff time needed to make use of it, so an intrusion detection system whose alerts nobody reads protects little. And the absence of past attacks isn't evidence of safety: never having been attacked doesn't lower the risk that a known flaw presents.

Three recurring decisions#

Several of these trade-offs meet in decisions every organization faces. Password policy is one. Requiring very frequent forced password changes seems to increase security, but it adds friction, and people respond with predictable variations, changing Spring2031! to Summer2031!, which attackers can guess. Current guidance, including the federal guidelines published by the National Institute of Standards and Technology (NIST), therefore favors long, unique passwords, screening out passwords that have appeared in breaches because attackers are likely to try those first, and requiring a change when compromise is suspected rather than on a calendar. If a breach exposes some users' passwords, those users should change them now and be warned against reuse. Because length matters so much, a policy that sets a low maximum length is a weakness, since it limits strength and pushes users toward predictable choices.

Patch timing is a second decision, and it balances speed against stability. Prompt patching closes known vulnerabilities, but an untested update can disrupt the systems it is meant to protect, so organizations balance speed against testing, particularly for critical systems. A common approach is to test quickly on a copy of the system and then patch promptly while monitoring for problems. A staged rollout releases an update to a small group first, ideally outside peak periods such as a store's busiest sales week, which limits the effect of a bad update. If patching is impractical, for instance because a machine runs equipment that the update would break, isolating the system on a restricted network limits its exposure. For a zero-day vulnerability, no fix yet exists (0004.e explains the term), so the only options are mitigations, such as restricting use of the affected tool, and monitoring its logs until the correction arrives.

Third-party risk is the last. Vendors and outside software libraries add capabilities and speed, since no school or company builds everything itself, but each one adds risk, because a weakness in the vendor's systems or the library's code becomes a weakness in yours. Organizations should assess vendors' security before contracting, by reviewing evidence of their security practices. Software projects should include only the dependencies they need, removing unneeded packages and watching the remainder for updates. Pinning library versions, so that the project uses a specific version until someone deliberately changes it, and reviewing updates before adopting them, keeps a compromised release from spreading into a project automatically. Using a vendor doesn't transfer an organization's duties: handing data to a vendor doesn't remove the need to manage the risk to that data. Dependence isn't always the riskier choice, though. A specialist's well-tested login service can be safer than custom authentication written in house, which is likely to contain subtle flaws, despite the dependency it adds. Weighing these options well requires knowing what the tools can actually do, and the most important of those tools, cryptography, is the subject of 0004.d.

• risk: the combination of the likelihood of a harm and its impact
• workaround: a way users bypass a burdensome control
• break-glass access: emergency access that bypasses a normal restriction, logged and reviewed after each use
• staged rollout: releasing an update to a small group before everyone
• pinning: fixing a dependency at a specific version until it is deliberately changed
• third-party risk: risk introduced by vendors and outside libraries

Practice: practice questions for 0004.c