Security Briefings: Phrases for Reporting & Discussing Security Issues
5 exercises on KEY PHRASES for security communications. Choose the most natural and professional option.
0 / 5 completed
1 / 5
Choose the best way to open a security incident update to stakeholders:
KEY PHRASE: "We've identified a vulnerability in..." This is the standard incident-opening phrase — specific, professional, and non-alarmist. It names the component (authentication module) without catastrophising. Real examples: "We've identified a vulnerability in the OAuth flow affecting session tokens"; "We've identified a vulnerability in the file upload handler that allows path traversal." Options A and D are far too vague and casual. Option B ("something's wrong") is alarmist without being informative. In security communications, precision matters — vague language erodes stakeholder trust and delays the right people taking action.
2 / 5
Which phrase best describes a limited blast radius during a security incident?
KEY PHRASE: "The impact is limited to users who..." Scoping impact precisely — with time bounds, user segments, or affected surfaces — is the core skill in incident communication. "The impact is limited to..." is the standard form used in post-mortems and status pages. Real examples: "The impact is limited to API consumers using the v1 endpoint"; "Impact is limited to EU-region accounts created before May 2025." Options B and C are informal and give no actionable scope. Option D minimises the issue without evidence, which damages credibility with security-aware stakeholders.
3 / 5
What is the most professional way to describe what your team did to contain an active attack?
KEY PHRASE: "We've mitigated by rotating... and blocking..." Mitigation language must be specific and action-oriented. "We've mitigated by..." followed by concrete actions — rotating credentials, blocking IPs, revoking tokens, patching the binary — gives stakeholders confidence that real steps were taken. Real examples: "We've mitigated by revoking all active sessions and forcing a password reset"; "Mitigated by patching the dependency and redeploying." Vague phrases like "we fixed it" or "the issue is resolved" provide no assurance about what was actually done and invite follow-up questions you don't want in a live incident.
4 / 5
You need to escalate a live security incident to senior leadership. Which phrasing is correct?
KEY PHRASE: "This is a P1 — we're treating it as an incident..." P1 is the industry-standard severity label for the highest-priority incidents. Naming it explicitly tells listeners exactly how serious it is — without requiring interpretation. "The on-call team is engaged" signals that the right response structure is already activated. Real examples: "This is a P1 — SEV1 posture, bridge open, all engineers on deck"; "P1 declared — incident commander assigned, customer comms in 15 minutes." Options A, C, and D rely on vague intensity words and don't invoke any response framework.
5 / 5
A security researcher reported a vulnerability to you privately. How do you respond professionally?
KEY PHRASE: "...responsible disclosure... coordinated release timeline" This response does three things the others don't: it names the process the researcher followed (responsible disclosure), acknowledges their effort, and commits to collaboration. "Coordinated release timeline" is the industry term for the period between fix and public disclosure — typically 90 days per Google Project Zero norms. Real examples: "Thank you for your responsible disclosure — we'll work with you on a 90-day coordinated release"; "We'd like to coordinate the disclosure timeline with you and credit your finding in the advisory." Options B-D are generic acknowledgements that don't build trust or demonstrate security programme maturity.