Security, Risk, and Compliance Controls
Core model
Security rests on confidentiality, integrity, and availability, supported by identification, authentication, authorization, and accounting. Authentication proves who you are; authorization decides what you may do. Questions deliberately swap them. Least privilege, separation of duties, and defense in depth are the recurring design principles: multiple independent controls so one failure is not total.
Risk language
Risk is commonly expressed as likelihood multiplied by impact. Treatment options are avoid, reduce, transfer, and accept, and acceptance should be a documented decision by someone empowered to make it. Controls fall into categories: preventive (stops an event), detective (reveals one), and corrective (restores after one). A control can be administrative, technical, or physical.
Compliance is not security
Compliance demonstrates that required controls exist; security is whether they actually reduce risk. Passing an audit while a known vulnerability sits unpatched is the classic trap: evidence of a control is not evidence of effectiveness.
Data protection
Know encryption in transit versus at rest, key management as a separate problem from encryption, data classification driving handling rules, and audit logging that is protected from the administrators it records.
Traps
Options that grant broad permanent access to save time, disable logging during troubleshooting, or share credentials among staff are wrong even when they solve the immediate issue. Also watch for confusing a vulnerability (a weakness) with a threat (an actor or event) and a risk (the combination with impact).
Worked example
A contractor needs read access to one folder for two weeks. The correct answer is a time-bound, least-privilege grant with logging, approved and recorded, then revoked. Standing administrative access is not the answer, however convenient.