Ask Yourself

What It Suggests

Is this a known/reported vulnerability, or do you suspect an active compromise?

Active compromise needs immediate, careful handling — different from a routine patch

Was this flagged by a scanner/tool, a person, or discovered by you?

Helps us understand how confirmed vs. theoretical the issue currently is

Does it affect user data, payments, or authentication specifically?

These carry higher urgency and different handling than a lower-impact misconfiguration

Is the vulnerable code/system in production right now?

Determines whether this needs to be treated as urgent

Do you have any logs, scan reports, or evidence of the issue?

Speeds up verification significantly

Is this part of a compliance requirement (GDPR, PCI-DSS, SOC 2, etc.)?

Changes what "fixed" needs to mean, and what documentation may be needed

Category

What It Covers

Vulnerability Scanning & Assessment

Finding out what's exposed before it's exploited

Injection Vulnerabilities

Attacker-controlled input manipulating queries or commands

Cross-Site Scripting (XSS)

Malicious scripts executing in users' browsers

Authentication & Authorization Vulnerabilities

Weak or broken access control letting the wrong people in

CSRF & Session Attacks

Attacks exploiting trusted sessions or forged requests

API Security Issues

Exposed, unauthenticated, or poorly rate-limited endpoints

Data Exposure & Privacy Leaks

Sensitive data accessible where it shouldn't be

Security Misconfiguration

Default settings, open ports, or missing hardening

Dependency & Supply Chain Vulnerabilities

Vulnerabilities inherited from third-party packages

Encryption & Data Protection Issues

Data not properly encrypted in transit or at rest

Active Breach & Incident Response

A compromise has already happened and needs immediate handling

Compliance & Security Standards

Meeting GDPR, PCI-DSS, SOC 2, and similar requirements

DDoS & Abuse Protection

Defending against traffic floods and automated abuse

What to Share

Why It Helps

How the issue was identified (scanner, report, your own discovery)

Helps us understand how confirmed the issue is and where to start verifying

Any scan reports, error logs, or evidence you already have

Speeds up verification significantly and avoids duplicate work

What data or systems are potentially affected

Determines urgency and what precautions to take before making changes

Whether the affected system is currently live/in production

Changes how carefully and quickly we need to move

Your stack (language, framework, hosting)

Vulnerabilities and fixes are often stack-specific

Any compliance requirements this needs to satisfy

Changes what "fixed" needs to look like, and what documentation may be needed

Instinct

Why It Doesn't Help

Do This Instead

Patching the symptom a scanner flagged without understanding the real risk

Can leave the underlying issue exploitable in a slightly different form

Understand the actual vulnerability and attack path before patching

Publicly discussing or posting about a suspected breach before confirming it

Can alert an active attacker or cause unnecessary panic before facts are clear

Confirm the situation privately first, then decide on communication

Taking a system offline entirely as a first response to a suspected issue

Sometimes necessary, but often not — and can destroy evidence needed to understand what happened

Assess whether isolation or monitoring is sufficient before a full shutdown

Rotating all credentials without knowing which ones were actually exposed

Can cause unnecessary downtime and doesn't guarantee the real exposure is addressed

Identify exactly what was exposed before deciding what needs rotating

Assuming a low CVSS score means a vulnerability isn't worth fixing

Severity scores don't account for your specific context — a "low" issue can be critical in the wrong place

Assess actual exploitability and impact in your specific setup

Deleting logs or evidence while trying to "clean up" after an incident

Removes the ability to understand what happened and confirm it's fully resolved

Preserve logs and evidence until the investigation is complete

Step

What Happens

1. Tell us what's happening

Share how the issue was found, what's potentially affected, and whether it's active or already contained

2. We verify and assess real impact

We confirm the vulnerability is real, understand its actual exploitability in your specific setup, and determine urgency

3. We fix it without breaking what works

The fix addresses the actual vulnerability and attack path, and is tested to confirm it doesn't introduce new issues

4. We explain what happened and what was done

You get a plain-English explanation of the vulnerability, its real risk, and the fix — useful for your own records or reporting to stakeholders

5. We advise on what to monitor going forward

If the issue suggests a broader pattern worth addressing, we tell you what else is worth reviewing

Question

Answer

I think we've been breached right now — what do you need from me?

Reach out immediately and tell us what you're seeing. We'll guide you through what to check and what not to touch in the meantime.

Will you need full access to our systems to assess a vulnerability?

We ask for the minimum access needed to verify and fix the specific issue — we'll explain exactly what's needed before starting.

Can you help us meet a specific compliance requirement (GDPR, PCI-DSS, SOC 2)?

Yes, for the technical security controls involved — we'll be clear about what's in scope and what may need additional specialist review.

Is this confidential?

Yes. Security engagements are treated with strict confidentiality, and an NDA is available on request.

What if the vulnerability turns out to be less serious than we thought?

We'll tell you honestly — including if it's lower priority than initially assumed — rather than treating everything as urgent by default.

Do you work with our specific stack and hosting setup?

Very likely. We work across the major languages, frameworks, and cloud/hosting platforms.