Cybersecurity Analysis
This domain tests how a business analyst identifies, structures, and communicates security needs during change. It is an analysis discipline: clarify assets, stakeholders, threats, controls, requirements, traceability, and solution evaluation. It is not penetration testing or security engineering, although the analyst must collaborate with those specialists.
Core rules and concepts
- Treat security as a quality and non-functional requirement with measurable acceptance criteria, not a late technical add-on.
- Model assets, data flows, actors, and trust boundaries; classify data by sensitivity and regulatory exposure.
- Use the CIA triad (confidentiality, integrity, availability) to frame objectives and STRIDE to prompt threat discussion.
- Distinguish threat, vulnerability, and risk: risk is commonly likelihood multiplied by impact; controls reduce likelihood or impact, leaving residual risk that an accountable owner accepts.
- Record risk treatment as avoid, mitigate, transfer, or accept, and link each security requirement to a control and a risk.
- Elicit from security, privacy, legal, operations, and business owners; capture assumptions, constraints, and compliance obligations.
Worked example
A patient portal stores protected health information. The analyst maps patients, clinicians, an identity provider, and a payment processor, with trust boundaries at browser, API, and database. A threat is an external attacker using stolen clinician credentials to view another patient's record; impact is high and likelihood is medium, so risk is high. Controls are MFA, role-based access, and audit logging. The requirement becomes: 'The system shall require MFA for clinician accounts and log every record access with user, timestamp, and patient identifier; access is denied unless the role permits it.' Acceptance tests cover the role matrix, MFA enforcement, and log retention. The privacy owner accepts residual risk after control verification.
Traps that cost marks
Vague requirements such as 'the system must be secure'; treating compliance as equivalent to security; confusing a vulnerability with a threat or risk; ignoring insiders, vendors, and operational monitoring; and omitting residual-risk ownership or requirement-to-control traceability.