Risk, compliance and the first hour of an incident
Security is also a management job: someone has to decide which risks to fix, which rules apply, and what happens when an attack gets through anyway. This lesson gives you the language security teams use for that job (policies, risk treatment, NIST CSF 2.0, CIS Controls, ISO 27001, PCI DSS) and a calm, ordered first hour for the morning a ransom note appears on a screen.
By the end you can
- Tell a policy, a standard and a procedure apart, and say who owns each
- Choose a risk treatment (reduce, transfer, avoid or accept) and name the right risk owner
- Place security work in the six functions of NIST CSF 2.0, and say what CIS Controls, ISO 27001 and PCI DSS are each for
- Run the first hour of an incident: confirm, contain without destroying evidence, escalate, record and communicate
- Build an incident timeline in SQL and plan a tabletop exercise
The everyday picture
Think about fire safety in an office building. The owner writes a fire safety plan and signs it. The fire code is the law: it says how many exits you need, and an inspector checks. Somebody walks the building once a year and asks what could catch fire and how bad it would be. The owner buys sprinklers for the kitchen, insurance for the building, and moves the paint store out of the basement. Twice a year everyone does a fire drill, so the first real alarm is not the first time anyone has thought about it.
When the alarm does ring, good habits matter more than courage. You close the door behind you to slow the fire, you don't open a hot door to see how bad it is, you call the fire brigade and let one person take charge, and you meet at the assembly point instead of shouting across the building. Afterwards, investigators want the scene left alone so they can find the cause. Security works the same way: a plan and rules before, a short list of calm steps during, and evidence kept for after.
Who decides what: policies, standards and procedures
In Thinking like an attacker you listed assets and scored risks. Somebody now has to decide what to do about them, and write it down so that about 1,920 store staff, the engineers and the head office all follow the same rules. Security documents come in layers, and each layer has a different owner.
- Policy: a short statement of intent from leadership. "Every account that can reach customer or payment data uses multi-factor authentication." An executive signs it. It says what and why, and it changes rarely.
- Standard: the specific, measurable rules that make the policy true. "Admin and VPN accounts use passkeys or hardware security keys; SMS codes are not accepted; sessions expire after 12 hours." The security team owns it and updates it as technology changes.
- Procedure: the steps for one job. "How the service desk enrols a new store manager's passkey, in nine steps." The team that does the work owns it.
- Guideline: advice that helps people do the right thing, without being mandatory. "How to spot a fake delivery-note email."
The layers let each person read the level they need: leadership doesn't approve every setting, and a store manager doesn't read a 40-page standard. An audit walks the chain the other way: do the procedures carry out the standards, and do the standards meet the policy?
Real systems can't always meet a standard. The old till software might not support passkeys yet. The answer is a documented exception: what rule is missed, why, the compensating control in the meantime, an end date, and the signature of the person who owns the risk. Exceptions without end dates are how a policy quietly stops being true.