Security governance decides which risks an organization will carry, who answers for them, and how anyone would know the controls work. Technical security asks how to stop an attack; governance asks whether stopping it is worth the cost, and whose call that is. The chapters run from first principles through policy, risk, frameworks and compliance to identity, threats, operations, incidents, continuity, data protection and software. Orientation for study, not legal or compliance advice, and not affiliated with any certification body.
Each chapter opens with the short version. Tap one to read the detail.
The principles behind every control decision
~2 min
Classify a failure by what was lost: confidentiality, integrity or availability. Then ask who proved their identity, what they could do, and what single point the outcome rested on.
Start with the harm. Confidentiality fails when the wrong person reads something, integrity when data is wrongly changed or destroyed, availability when people cannot get to it on time.
Then trace access. Authentication establishes who someone is, authorization sets what they may do, and accounting records what they did. The later steps lean on the first, so a team's shared login produces a log that names nobody. Non-repudiation lets an outside party check who originated data, which a digital signature supports because the private key belongs to the signer alone.
Least privilege gives each user or process only what its tasks require, and need-to-know applies that to specific information, so a job reason counts and rank does not. Separation of duties splits a sensitive task so that misuse takes collusion. Defense in depth mixes administrative, technical and physical layers that fail in different ways. Zero trust adds that sitting inside the network earns nothing, so verification continues.
Say one clerk can both create a vendor and approve its payment. A perfect audit log only records the theft; splitting the steps stops one login finishing the job.
The trap is assuming more controls always mean more security. Needless ones waste resources and hamper use. The White House Office of Management and Budget (OMB) warns that if outdated password rules lead staff to reuse passwords or keep them insecurely, attackers benefit.
Rule: name the property lost, the identity involved and the single point of failure, then pick a control whose cost you can defend.
Policy, roles and running the program
~2 min
Policy sets direction, standards and procedures carry it out, and named owners answer for the result. A healthy program measures more than incidents and records its exceptions.
The documents form a hierarchy. Policy gives management's direction, a standard fixes a technology or setting and is usually mandatory, a guideline offers advice you can satisfy several ways, and a procedure lists the steps. Issue-specific policies, such as acceptable use, need more frequent review because technology outdates them sooner.
The information owner sets rules for specific information, the system owner is accountable for acquiring, running and retiring a system, the administrator handles setup and accounts, and users follow the rules. A chief information security officer (CISO) manages the whole program. Banking supervisors add three lines of defense: frontline units that create risk, a separate risk function, and internal audit checking both.
Federal practice grades information low, moderate or high by the damage its loss would do, separately for each of the three properties. So a public site may carry no confidentiality impact and still matter for integrity. The National Institute of Standards and Technology (NIST) distinguishes implementation, effectiveness, efficiency and impact, which means a high patch percentage shows activity and does not by itself show lower risk.
Say a team cannot meet a logging standard until a migration finishes. A recorded exception states the reason, the duration and the plan back to compliance, and someone accepts the risk knowingly.
The trap is treating an unrecorded workaround as harmless. It carries the same risk, except that nobody chose it and nobody will revisit it.
Rule: every rule needs an owner, a review trigger and a recorded path for the cases it cannot cover.
Risk: naming it, sizing it and deciding what to do
~2 min
Risk combines an event's harm with its likelihood, so a weakness alone is not yet a risk worth funding. You then accept, avoid, mitigate or transfer it, and someone owns what remains.
A vulnerability is a flaw, and a threat source is whatever could take advantage of it, which need not be hostile: floods and honest mistakes count.
Qualitative assessment uses levels such as low and high, which communicate well but make close risks hard to rank. Quantitative assessment uses numbers that keep their meaning elsewhere, so it supports cost-benefit comparison. The classic calculation multiplies the estimated loss per event by the expected events per year. A $40,000 event once every four years and a $500 event twenty times a year both come to $10,000 annually, so treat the result as a comparison, not a forecast.
You can accept, avoid, mitigate, or share and transfer. Senior leaders set appetite, the broad amount of risk the organization will take, and tolerance is the allowed variation, normally fixed at program level. Inherent risk is the exposure before you act and residual risk is what is left after. It is never zero, so someone must sign for it. A register holds every risk; a profile ranks the most significant, each with a response and an owner.
Say you move payments to a vendor and buy cyber insurance. US banking guidance holds a bank as responsible as if it did the work itself, and NIST notes that transfer lowers neither likelihood nor consequences. The Government Accountability Office reported in 2021 that key policy terms lacked standard definitions, so read the wording.
The trap is treating transfer as an exit. It moves some of the cost, and the failure still lands on your customers.
Rule: estimate harm and likelihood separately, write down who accepted what is left, and never count a contract as making a risk disappear.
Controls, frameworks and proving they work
~2 min
Sort a control by its form and its job, and use frameworks to set outcomes. Evidence about controls counts only when its source, scope and period fit your question.
By form, controls are administrative, physical or technical, so a written firewall procedure stays administrative. By job, preventive controls act before an unwanted event, detective ones find it afterward, corrective ones repair it or its cause, and deterrents discourage the attempt. A compensating control gives comparable protection in place of a baseline control, such as segmenting a device you cannot patch.
NIST's Cybersecurity Framework (CSF) 2.0 describes outcomes under six functions, with govern at the center of identify, protect, detect, respond and recover. They form no sequence or ranking. Comparing a Current Profile with a Target Profile yields a prioritized plan, and since you chose the target from your own risk, not every gap is a defect. NIST's SP 800-53 is a catalog you tailor from a baseline matched to system impact, so dropping a control needs a risk reason.
People grading their own system know it deeply but have little incentive to fault its design, while an independent auditor has no stake. Continuous monitoring keeps decisions on current facts, though alerts nobody watches protect nothing. Red teams test whether defenses work: in one Cybersecurity and Infrastructure Security Agency (CISA) assessment, a mature organization never detected the team.
Say a vendor sends a System and Organization Control (SOC) 2 type 1 report and an ISO 27001 certificate, both covering its data center, and you are buying its support portal. Type 1 does not address operation across a period, as type 2 does, and neither document describes what you are buying.
The trap is reading a certificate as a finding about your own risk. It is evidence from outside, and you still have to test its scope.
Rule: for any evidence, ask who produced it, exactly what it covered, and over what period.
Compliance, privacy and legal duties
~2 min
Each regime governs a different domain, so the data, the people and the place decide which rules apply. Retention and preservation can conflict, and counsel settles how this applies to you.
The Health Insurance Portability and Accountability Act (HIPAA) protects health information, and the Sarbanes-Oxley Act targets accounting errors and fraud. The Payment Card Industry Data Security Standard (PCI DSS) is an industry standard, not a statute; the Federal Trade Commission (FTC) reported in 2016 that major card companies required PCI DSS audits of businesses handling over 1 million card transactions a year. The EU's General Data Protection Regulation (GDPR) reaches beyond the EU. Personally identifiable information can single someone out alone or once combined with other data.
OMB's principles for federal agencies ask for authority to collect, only what is necessary, and no longer than the purpose needs. NIST adds that authorized processing can itself cause harm, such as embarrassment or discrimination, so security alone falls short and privacy belongs in the plan phase. HIPAA gives one example of access requests: generally 30 days to act and one extension. Other laws set their own terms.
Breach duties begin with identifying the applicable laws, because each state has its own. HIPAA presumes an impermissible disclosure is a breach unless an assessment shows a low probability of compromise.
Say a financial firm's job will next week purge customer files two years past last use, and a demand letter arrives today. US court rules expect reasonable preservation steps once a lawsuit is anticipated, even though the FTC's Safeguards Rule sets that two-year disposal limit for covered institutions, with exceptions for retention the law requires. Deletion schedules need a way to pause, and counsel sets a hold's scope.
The trap is planning to HIPAA's 60 days. Notice is due without unreasonable delay, 60 is the ceiling, and the clock runs from when you knew or reasonably should have.
Rule: identify the data, the people and the place first, let those pick the laws, and take the specifics to counsel.
Identity, access and the people behind the accounts
~2 min
Access should follow the job through hiring, moves and departure, with reviews catching what slips. People controls such as screening, offboarding and time away do work sign-in technology cannot.
Grant access at hiring, change it at a move, and remove it at departure. Departure is the sharp edge, because former staff keep what they know and NIST links sabotage to knowledge or threat of termination. So cut access promptly and recover keys, badges and tokens. Reviews ask whether each entitlement is still justified, ordinary accounts included. Role-based access works through predefined roles, while attribute-based access decides at request time from facts such as device health.
Keep administrator power off everyday accounts. Privileged access tools can vault passwords, record sessions and grant access just in time, but OMB warns that their brief single-factor credentials do not replace multi-factor authentication (MFA). Two passwords are still one factor, and a one-time code can be phished, which is why a 2022 OMB memo requires phishing-resistant methods for agency staff. It also told agencies to drop special-character and rotation rules, and version 2.0 of CISA's voluntary performance goals sets a 16-character minimum where technically feasible. Single sign-on centralizes control and makes its signing keys a single point of failure.
Aim background checks at roles touching sensitive data. If you use a background-reporting company in the US, legal steps follow, including written permission and advance notice of an adverse decision. Federal Reserve guidance for banks treats two consecutive weeks away from sensitive duties as a basic control, electronic access included, because it says most frauds need someone continually present.
Say an analyst moves from finance to marketing and keeps the finance access. Nothing breaks, and the old access stays live until someone looks.
The trap is treating joiners and leavers as the whole lifecycle. Moves make no noise, so access quietly piles up there.
Rule: tie every entitlement to a current job reason, and make removal an event triggered by the change, not a cleanup.
Who attacks, how, and what the patterns are called
~2 min
Motive shapes what an attacker does, and a route in can run through a person, a reused credential or something you already trust. Shared vocabulary lets defenders compare notes.
Criminal groups want money, foreign intelligence services collect information and may disrupt infrastructure, some attackers want thrills, and insiders start with access. Insider harm can be malicious, complacent or accidental.
Social engineering works on the person: phishing by email, vishing by voice, smishing by text, and pretexts such as posing as an existing customer. Tells include a slightly altered sender address, a link that goes somewhere other than it says, and false urgency. Malware sorts by behavior: a virus needs a host program, a worm spreads alone, a Trojan hides inside something useful, and ransomware withholds access pending payment. Your attack surface is every boundary point where someone could enter, interfere or extract data, and reducing it starts with an inventory.
Spraying tries one password across many accounts to stay under lockout limits, while stuffing replays credentials stolen elsewhere, so reuse defeats even a strong password. Indirect attacks borrow trust: a watering hole is a real site altered to carry malicious content, and a software supply chain attack tampers with a product before it ships.
The Cyber Kill Chain gives a sequence of intrusion stages, while the ATT&CK catalog names tactics and techniques; a mapped technique says what was done, not what comes next.
Say a vendor's real mailbox is taken over and sends new bank details. The address is genuine, so confirm through a contact you already hold. If money has moved, call your bank at once to request a recall, then file with the FBI's Internet Crime Complaint Center.
The trap is trusting appearance. Red flags are indicators, so a message that looks clean can still be fraudulent.
Rule: judge a request by what it asks you to do, and confirm anything that moves money or credentials through a channel the requester did not supply.
Running the defenses: monitoring, patching and the network
~2 min
Operations turns policy into routines: log and review, scan and fix, change under control, and segment the network. A tool is not a working control until someone tunes it and acts on it.
Collect logs that serve detection, guard them against tampering, retain them as risk or regulation demands, and get an alert if logging stops. A security information and event management (SIEM) tool correlates sources but still needs rules and people. A security operations center triages alerts, and despite the shared letters it is not a SOC report.
Vulnerability work cycles through scanning, ranking, fixing and rescanning. Patching weighs opposite risks: attackers keep using old flaws, and untested changes break things. Where a patch would endanger availability or safety, compensating controls carry the load. A scan reports what a tool recognizes, while a penetration test uses skilled people under agreed rules to find what can be exploited. Change control aims to stop anything weakening security unknowingly, and a baseline gives you an approved state to measure drift against.
Segmentation limits a breach, and a demilitarized zone buffers internal from external networks. Deny by default in both directions and review the rules. Inline sensors can block traffic, while passive ones see a copy and usually cannot. Email authentication covers mail claiming your own domain, and filtering what arrives is a separate job. At the endpoint, antivirus leans on known signatures, and endpoint detection and response adds live monitoring and automated action.
Say a scanner rates a flaw on an internal test box critical, while a lower-rated flaw on your internet-facing gateway appears in CISA's catalog of known exploited vulnerabilities. The Common Vulnerability Scoring System expresses impact, not whether anyone is using the flaw, so the gateway comes first.
The trap is equating a deployed tool with working protection. In one CISA assessment, the tools, the endpoint platform among them, missed a red team moving between systems.
Rule: for each control, ask what it would have caught last month and who would have acted.
Incident response: decide early, act in order
~2 min
Response is a loop of preparation, detection, containment, eradication, recovery and review, and its hard calls belong before the incident. Containment trades speed against evidence and service.
CISA's federal playbook moves from preparation to detection and analysis, then containment, eradication and recovery, then review. Fresh signs of compromise send you back to analysis, so it is a loop. Preparation leads because you cannot train people or set up evidence collection after the first alert. Name a coordination lead and arrange out-of-band channels, since an adversary may be reading your ordinary ones.
Containment cuts off the adversary's access, and every option costs something: service disruption, time, or evidence. Acting early can tip off a watching attacker, and delay lets them dig in. Chain of custody tracks who held evidence, when and for what reason.
The FTC recommends consulting with your law enforcement contact about the timing of notice, so it does not impede the investigation. The Department of Justice warns against hacking back, because it may violate federal law and can undermine an investigation. Settle ransom authority in advance too. The US government strongly discourages paying, payment guarantees nothing, and it can carry sanctions risk, though the Treasury's sanctions office treats prompt reporting and cooperation as significant mitigating factors.
Say an analyst finds an intruder on a file server at 2 a.m. and wants to reimage it. That can erase the record of how far the intruder got. The FTC's advice is to take affected machines offline without powering them off until forensic experts arrive.
The trap is cleaning up first because it feels like progress. You cannot eradicate what you have not scoped, and the review will lack its facts.
That review, which CISA calls a hotwash, exists to change something: root cause, new detections, policy and training. Look for causes, not culprits.
Rule: settle who decides, who speaks and how evidence is kept before the incident, and let every incident change a detection or a plan.
Keeping the business running and getting systems back
~2 min
A business impact analysis tells you what a disruption costs and informs recovery targets. Recovery time limits downtime, recovery point limits data lost, and only a tested restore shows whether you can meet either.
A business impact analysis (BIA) estimates what a disruption would cost in lost income, added expense and penalties, and it produces recovery priorities. A risk assessment finds the loss scenarios; the BIA sizes their consequences and shows your dependencies.
The recovery time objective (RTO) is how soon a function must return. The recovery point objective (RPO) is the moment data is restored to, counted back from the disruption. A business continuity plan keeps the business going, and the IT disaster recovery plan restores the systems beneath it. Set out succession, alternate worksites and manual workarounds too.
The 3-2-1 rule means three copies, two kinds of storage and one copy offsite. Ransomware adds a need for offline or isolated copies, and CISA's performance goals call for testing backups and recovery at least yearly. After an attack, remove the intruder before reconnecting anything, because attackers often keep several backdoors, and check backup integrity before restoring. Alternate sites vary by how much is ready: hot runs fully, warm lacks software and data, cold lacks computers.
Exercises climb in realism from walkthrough to tabletop to functional to full-scale. Build a tabletop from objectives and finish with an after-action report so the talk becomes changes. A tabletop tests roles and plans; it cannot show that failover works.
Say a system has a four-hour RTO and a one-hour RPO, with hourly backups. The backups meet the RPO, yet a nine-hour restore still misses the RTO.
The trap is treating backup frequency as recovery speed. Frequent copies shrink data loss and do nothing for how long the restore takes.
Rule: set both targets from business impact, then time a real restore and compare it with the objective.
Cryptography and protecting data through its life
~2 min
Governance needs cryptography's roles more than its math: keys for secrecy, hashes for change detection, signatures for origin. Data needs protection at every stage, ending with disposal you can defend.
Symmetric cryptography shares one secret key, so delivering it safely is the problem. Asymmetric cryptography uses a pair: the public key encrypts or verifies, and the private key decrypts or signs. A hash reduces input to a fixed-length digest designed to be one-way, and comparing digests reveals change. Salting mixes a non-secret value into a password. Certificates tie a public key to its owner, and trust runs up a chain to a root authority you already accept.
Encrypt data both stored and moving, since outside your boundary cryptography may be all you have. Key policy runs from generation through destruction, and a cryptoperiod caps how long one key stays active. An approved-algorithm policy plans the exits. NIST's status terms run acceptable, deprecated, legacy use and disallowed, and legacy use never covers protecting new data.
Data loss prevention watches what is leaving, and the FTC advises calibrating noisy rules rather than switching them off. Retain personal information no longer than its purpose needs. NIST's 2014 media guide, withdrawn in 2025 and replaced, names three sanitization methods: clear resists simple recovery, purge defeats laboratory techniques, and destroy also ruins the media. It warned against relying on degaussing alone for flash storage, so check the current edition before you pick.
Say a team encrypts a customer database and keeps the key in that server's configuration file. An attacker who reaches the server holds both.
The trap is treating encryption as the end of the job. It moves the problem to the keys.
Rule: for any protected data, ask where the key lives, who can reach it, and what happens when it or the algorithm must be retired.
Governing software you build and services you buy
~2 min
Plan security across a system's life, with gates that catch different kinds of flaw. Cloud moves some duties to the provider and leaves others with you, so write down who owns what.
Plan security from a system's start through disposal rather than bolting it on. Threat modeling finds design flaws, while automated scans and tests find code bugs before release. Static analysis reads the code, and dynamic testing runs the software and examines the output. Dynamic testing raises few false alarms but tends to miss secrets written into the code, so a release gate needs both.
Class names let you ask about whole families of flaw. Injection means user input lands inside a query or command, and cross-site scripting comes from input left unvalidated or unescaped. A software bill of materials (SBOM) is a nested inventory of components, and it only starts the job, because a flaw can surface in old code on any day. Keep checking it against known-vulnerability databases.
In the cloud, the split depends on the service model. Software as a service leans heavily on the provider, infrastructure as a service leaves much with you, and some duties stay joint. Exposure needs no exploit: the FTC described data loaded onto a server whose firewall was disabled. So monitor for misconfiguration, audit for over-privileged accounts, and give people and programs separate access keys. Lock-in, depending on one provider's particular services, can be worth it, so decide per system.
Say a department signs up for an online tool nobody approved, and it cannot connect to your identity provider. It keeps its own accounts, so offboarding never reaches them. A policy naming who may approve such tools gives staff a legitimate path.
The trap is assuming a provider's security covers your use of it. Your own access and configuration choices can still expose the data.
Rule: for each system, write down who secures which layer, then confirm your gates and reviews reach the part that is yours.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.