How to Present Security Findings in English

Security findings need to be communicated with precision. The wrong word choice can either downplay a serious risk or trigger unnecessary panic. Whether you are writing a penetration test report, presenting findings to a development team, or escalating to leadership, the language you use shapes how people respond. This post gives you the vocabulary and phrases to communicate security issues with clarity and professionalism.

Key Phrases

Opening a security finding:

• “We identified a SQL injection vulnerability in the user authentication endpoint.”
• “During our review, we discovered that session tokens are not invalidated on logout.”
• “The audit revealed that sensitive data is being logged in plaintext.”
• “We found a misconfiguration in the S3 bucket policy that exposes customer records.”

Describing severity and impact:

• “This is rated critical with a CVSS score of 9.8.”
• “The blast radius would include all authenticated users — approximately 40,000 accounts.”
• “The attack surface includes any unauthenticated HTTP endpoint on the public API.”
• “This vulnerability could allow an attacker to achieve remote code execution.”
• “The potential impact is data exfiltration of personally identifiable information.”

Recommending remediation:

• “To remediate this, I recommend parameterising all database queries.”
• “The fix involves rotating the exposed credentials immediately.”
• “As a short-term mitigation, we suggest blocking the affected endpoint at the WAF.”
• “The recommended remediation timeline for critical findings is 24 to 72 hours.”

Escalation language:

• “Given the severity, I’m escalating this to the security team lead.”
• “This requires immediate attention from the engineering manager.”
• “I’d recommend convening an incident response call within the hour.”
• “We need to notify our data protection officer given the potential GDPR implications.”

How to Use This in Practice

Security reporting follows a standard structure: finding → severity → evidence → impact → remediation → timeline. When you present findings in this order, even non-technical stakeholders can follow the logic and make informed decisions.

Severity levels are typically described as critical, high, medium, and low. Critical and high findings need urgent language: “This requires immediate action.” Medium findings can use measured language: “This should be addressed in the next sprint.” Low findings are often described as “best-practice improvements” or “hardening recommendations.”

CVSS scoring (Common Vulnerability Scoring System) gives findings a numeric score from 0.0 to 10.0. When presenting a score, always explain what it means: “The CVSS score is 8.1, which classifies this as high severity, primarily because it is remotely exploitable and requires no authentication.”

The blast radius refers to the scope of potential damage if a vulnerability is exploited. Being specific here builds credibility: “The blast radius is limited to internal admin accounts — external users are not affected.”

Example Conversation

Olena (Security Engineer): “I’d like to walk you through the findings from last week’s audit. We identified a critical vulnerability in the password reset flow. The attack surface includes the public-facing reset API, which accepts user-supplied tokens without rate limiting. The blast radius would be full account takeover for any user whose email address is known to an attacker. The CVSS score is 9.1.”

Dev Lead: “How quickly do we need to fix this?”

Olena: “Given the severity, remediation should happen within 24 hours. To remediate this, I recommend adding rate limiting at the API gateway level and implementing token expiry of 15 minutes. As an immediate mitigation, we can disable the endpoint until the fix is deployed. I’m escalating this to the engineering manager now.”

Practice Tips

1. Rewrite a CVE summary: Find a public CVE entry on the National Vulnerability Database (nvd.nist.gov) and rewrite the technical description in your own words, using the phrases from this post. This practises translating dense security jargon into clear professional English.

2. Practise the severity ladder: Take four security findings of different severity levels and write one sentence about each that starts with the appropriate urgency — “This is critical and requires…” down to “This is a low-priority hardening recommendation.” Notice how your tone and verb choices shift across the severity scale.

3. Mock a stakeholder briefing: Present a fictional security finding to a friend or colleague who plays a non-technical manager. Practise using plain-language equivalents alongside technical terms: “The attack surface — that is, the entry points an attacker could use — includes…”