CSG cheat sheet
CSG · Keep the key ideas within reach.
Security Governance
Governance sets direction and accountability; management runs the day-to-day controls. Governance answers "who decides and who is accountable," not "which firewall rule applies."
Three governance structures: board/executive committee (strategic risk appetite), steering committee (prioritization and funding), and security working groups (operational alignment).
Risk appetite is the amount of risk the organization is willing to accept in pursuit of objectives; risk tolerance is the acceptable variation around that appetite for a specific category.
Separation of duties: the person who approves a change should not be the person who implements it; the person who grants access should not be the person who audits it.
A security charter documents mandate, scope, authority, reporting lines, and decision rights of the security function; without it, security has no enforceable authority.
Key governance metrics: percentage of projects with security sign-off, time to remediate critical findings, and coverage of the asset inventory. These are reported upward, not to engineers.
The three lines model: first line owns and manages risk, second line (risk/compliance) monitors and advises, third line (internal audit) provides independent assurance.
Executive accountability cannot be delegated to the CISO alone; regulators increasingly hold the board responsible for cyber oversight and for approving the risk appetite statement.
Risk Management
Risk = likelihood × impact. Qualitative scales (e.g., 1-5) are common; quantitative methods use annualized loss expectancy (ALE) = single loss expectancy (SLE) × annualized rate of occurrence (ARO).
Risk treatment options: mitigate (apply controls), transfer (insurance, contracts), avoid (stop the activity), and accept (documented, with owner sign-off and expiry date).
Inherent risk is the risk before controls; residual risk is what remains after controls. Risk acceptance decisions apply to residual risk, not inherent risk.
Risk register entries need: asset/process, threat, vulnerability, likelihood, impact, inherent score, controls, residual score, owner, treatment plan, and review date.
A risk assessment methodology (e.g., NIST SP 800-30 style, ISO 31000 style) defines scoping, identification, analysis, evaluation, and treatment; consistency matters more than the specific framework chosen.
Threat modeling (e.g., STRIDE) identifies design-level risks early; it complements, not replaces, periodic enterprise risk assessments.
Business impact analysis (BIA) determines recovery time objective (RTO) and recovery point objective (RPO); these feed continuity planning and risk prioritization.
Risk heat maps plot likelihood against impact; a high-likelihood, low-impact risk and a low-likelihood, high-impact risk require different treatment strategies even if scores match.
Compliance and Regulatory Requirements
Compliance is conformance to requirements; it is not the same as security. An organization can be compliant and still be insecure, or secure without being compliant.
Common regimes: GDPR (EU personal data), HIPAA (US health data), PCI DSS (cardholder data), SOX (US financial reporting controls), and sector-specific rules such as NERC CIP for utilities.
GDPR principles: lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability.
Data subject rights under GDPR include access, rectification, erasure, restriction, portability, and objection; controllers must respond within one month, extendable by two.
PCI DSS scope is reduced by network segmentation and tokenization; the cardholder data environment (CDE) defines what must be protected.
Evidence for audits must be current, attributable, and retained for the required period; screenshots without dates or owners are weak evidence.
Compliance mapping: one control can satisfy multiple frameworks (e.g., access review satisfies SOX ITGC, ISO 27001 A.9, and PCI DSS 7). Map once, evidence many times.
Regulatory breach notification timelines differ: GDPR requires notification to the supervisory authority within 72 hours of awareness where feasible; contractual and sector rules may impose tighter deadlines.
Security Policies, Standards and Procedures
Hierarchy: policy (management intent, why) → standard (mandatory requirements, what) → procedure (step-by-step, how) → guideline (recommended, non-mandatory).
A policy must state purpose, scope, roles and responsibilities, policy statements, exceptions process, and review cycle; it should be approved by executive management.
Exception management: exceptions require a documented business justification, compensating controls, an approver with authority, and an expiry date for periodic re-review.
Policy review cadence is typically annual, or upon significant change (merger, new regulation, major incident); version control and approval records are audit evidence.
Standards are mandatory and measurable (e.g., "passwords must be at least 12 characters"); guidelines use "should" and are advisory.
Procedures must be testable and repeatable; if a procedure cannot be followed by a trained person without tribal knowledge, it is incomplete.
Policy communication and acknowledgement records demonstrate awareness; regulators and auditors commonly request them.
Acceptable use policy (AUP) covers acceptable use of organizational assets, personal use boundaries, monitoring notice, and consequences of violation.