ISSAP cheat sheet

Risk = likelihood × impact; residual risk = inherent risk minus the effect of implemented controls. Risk treatment options are mitigate, transfer, avoid, and accept; acceptance must be documented with an accountable owner.

Control types: preventive (blocks), detective (identifies), corrective (restores), deterrent (discourages), compensating (substitutes when the primary control is infeasible). Defense in depth layers controls so no single failure is sufficient.

Frameworks: ISO/IEC 27001 specifies ISMS requirements; NIST CSF organizes outcomes as Govern, Identify, Protect, Detect, Respond, Recover; COBIT governs enterprise IT; SOC 2 reports on trust services criteria.

Segregation of duties prevents one principal from holding both request and approval authority; toxic combinations are pairs of entitlements that together create fraud or misuse potential.

Risk register fields: asset, threat, vulnerability, likelihood, impact, inherent rating, control, residual rating, owner, review date. A risk appetite statement sets the tolerance boundary; risk above appetite requires treatment.

Compliance mapping links each regulatory obligation to a control objective, then to evidence artifacts; a single control may satisfy multiple obligations (common control) to reduce assessment duplication.

Third-party risk tiers by data sensitivity, access level, and business criticality; contracts should carry right-to-audit, breach notification timelines, and data return/destruction clauses.

Key risk indicators are leading metrics with thresholds; key performance indicators measure control operation. Exceptions require a time-bound, approved risk acceptance, not a permanent waiver.

Metrics for GRC: percentage of risks with owners, mean time to remediate findings, control test pass rate, and open exceptions past due date.

Data categories: personal data (identifiable natural person), sensitive personal data, protected health information, cardholder data, and confidential business data each carry distinct obligations.

GDPR principles: lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, accountability. Data subject rights include access, rectification, erasure, portability, and objection.

Cross-border transfer mechanisms include adequacy decisions, standard contractual clauses, and binding corporate rules; Schrems II invalidated the EU-US Privacy Shield.

PCI DSS applies to any entity storing, processing, or transmitting cardholder data; its 12 requirements cover network security, encryption, access control, monitoring, and policy.

HIPAA Security Rule covers administrative, physical, and technical safeguards for electronic protected health information; the Privacy Rule governs use and disclosure.

SOX Section 404 requires management assessment and auditor attestation of internal control over financial reporting; IT general controls (change, access, operations) support it.

Breach notification: GDPR requires notification to the supervisory authority within 72 hours of awareness where feasible; contractual and sector rules may impose shorter windows.

Records retention must satisfy the longest applicable obligation; legal hold suspends routine destruction once litigation is reasonably anticipated.

Contractual and industry obligations (NDA, SLA, data processing agreements) are requirements too; a requirements register should record source, owner, and verification method for each.

Verification asks 'did we build it right' against specification; validation asks 'did we build the right thing' against stakeholder need. Both are required before acceptance.

Threat modeling methods: STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) for threat enumeration; attack trees and kill chains for adversary paths; DREAD or risk matrices for prioritization.

Architecture review boards gate designs against standards; design reviews compare the proposed architecture to reference architectures and produce traceable findings with severity and owner.

A requirements traceability matrix maps each requirement to design element, test case, and evidence; untraced requirements and orphan tests are both defects.

Test levels: unit, integration, system, and acceptance; security-specific testing includes vulnerability scanning, penetration testing, configuration review, and code review.

Control testing samples evidence over a period; a control is operating effectively only if it is designed appropriately and applied consistently.

Prototyping and pilot deployments validate scalability, operability, and control feasibility before full rollout; rollback criteria must be defined in advance.

Acceptance criteria should be measurable and include security exit criteria such as zero critical findings unresolved and documented residual risk acceptance.

Network segmentation reduces blast radius; zones are defined by trust level, and traffic between zones passes through a policy enforcement point (firewall, security group, service mesh).

Zero trust principles: verify explicitly, use least privilege, assume breach; identity, not network location, becomes the primary control plane.

High availability patterns: redundancy (active-active, active-passive), failover, clustering, and geographic distribution; single points of failure must be identified and removed or accepted.

Cryptography: symmetric (AES) for bulk data, asymmetric (RSA, ECC) for key exchange and signatures, hashing (SHA-2/3) for integrity. Key management covers generation, distribution, rotation, storage, and destruction.

Cloud shared responsibility: provider secures the underlying infrastructure; customer secures configuration, identity, data, and workloads. Misconfiguration is the dominant cloud risk.

Virtualization and container security depend on image provenance, registry scanning, runtime isolation, and minimal base images; hypervisor compromise breaks all guest isolation.

Resilience: RTO is the maximum tolerable downtime, RPO is the maximum tolerable data loss; backup tiers and restore testing must be validated, not assumed.

Logging and monitoring architecture centralizes time-synchronized logs in a protected, append-only store with defined retention to support detection and forensics.

Requirements sources: business objectives, legal/regulatory obligations, threat model output, data classification, and contractual commitments. Each requirement needs an owner and a verification method.

Functional security requirements describe what the system must do (authenticate, encrypt, log); non-functional requirements describe qualities (availability, performance, scalability, maintainability).

Data classification drives handling requirements: storage encryption, transmission protection, access restrictions, retention, and disposal method per class.

Baselines: hardening standards (CIS Benchmarks), secure configuration baselines, and patch SLAs differentiated by asset criticality and exposure.

Availability requirements derive from business impact analysis: RTO, RPO, and maximum tolerable downtime translate into architecture patterns and cost trade-offs.

Capacity and performance requirements must include peak load, growth projections, and degradation behavior under stress to avoid availability-driven security shortcuts.

Requirements must be testable: 'encrypt data at rest using AES-256' is verifiable; 'be secure' is not. Ambiguous requirements cannot be validated.

Interface requirements define trust boundaries between systems, including authentication protocol, data format, and rate limits for each external integration.

Identity lifecycle: joiner, mover, leaver. Provisioning on hire, access adjustment on role change, and timely deprovisioning on termination are the highest-value access controls.

Authentication factors: something you know, have, or are. MFA requires factors from different categories; two instances of the same category is not MFA.

Authentication assurance levels (NIST SP 800-63) rise from single-factor to phishing-resistant cryptographic authenticators; AAL2 requires MFA, AAL3 requires hardware-based verifiers.

Federation protocols: SAML 2.0 for browser SSO with XML assertions; OAuth 2.0 for delegated authorization; OpenID Connect adds an identity layer on OAuth 2.0 for authentication.

Access control models: RBAC assigns permissions to roles; ABAC evaluates attributes and policy; MAC uses labels and clearances; DAC lets owners grant access.

Least privilege and separation of duties apply at the entitlement level; periodic access recertification catches entitlement creep and orphaned accounts.

Privileged access management: vaulting, session recording, just-in-time elevation, and break-glass accounts with alerting and post-use review.

Accounting requires unique user IDs (no shared accounts), immutable audit logs, synchronized time, and retention aligned to legal and investigation needs.

Single sign-on concentrates risk: compromise of the identity provider is a systemic event, so the IdP requires strong authentication, monitoring, and hardened recovery.

Security architecture decisions should be recorded as architecture decision records: context, options considered, decision, consequences, and review trigger.

Policy hierarchy: policy (intent), standard (mandatory specifics), procedure (steps), guideline (recommendation). Lower tiers must not contradict higher tiers.

Exception management process: request, risk assessment, compensating control, time-bound approval by risk owner, scheduled re-review.

Maturity models (CMMI-style levels 1-5) assess process capability; a gap assessment compares current to target state and produces a remediation roadmap.

Security metrics should be outcome-oriented (time to detect, time to remediate, coverage of critical assets) rather than activity counts alone.

Audit readiness requires evidence collected continuously, not reconstructed at assessment time; control owners are accountable for evidence quality.

Independent assurance increases confidence: internal audit, external audit, and third-party penetration testing provide different levels of independence.

Evidence types: configuration exports, screenshots with timestamps, logs, test reports, tickets, and attestations. Evidence must be attributable and reproducible.

Red team exercises test detection and response, not just prevention; purple teaming pairs offensive testing with defensive tuning.

Continuous control monitoring automates evidence collection and alerts on drift from the approved baseline.

Findings should be risk-ranked and tracked to closure with a named owner and due date; repeat findings indicate a systemic control failure.

Threat intelligence informs requirements: known exploited vulnerabilities and adversary tactics should map to specific preventive and detective controls.

Attack surface analysis enumerates entry points (network services, APIs, user interfaces, supply chain) and prioritizes reduction.

Secure defaults and fail-safe behavior: systems should deny by default and fail closed for security-relevant functions.

Supply chain requirements include software bill of materials, dependency scanning, vendor security attestations, and integrity verification of artifacts.

Physical and environmental controls (access control, power, cooling, fire suppression) are part of infrastructure security requirements for on-premises assets.

Centralized directory with federated trust reduces credential sprawl; directory synchronization and its scoping must be designed to prevent privilege leakage.

Token-based authorization requires short lifetimes, audience restriction, signature validation, and secure storage; refresh tokens need rotation and revocation.

Policy decision point and policy enforcement point separation allows centralized authorization logic with distributed enforcement.

Session management: idle and absolute timeouts, secure cookie attributes, session fixation prevention, and logout that invalidates server-side state.

Machine identity (service accounts, certificates, workload identities) must be inventoried and rotated; unmanaged non-human identities are a common audit finding.