Straight answers.
We had a pen test last year. Why would we need another one?
Your environment changed. New features shipped, new infrastructure stood up, new people joined. A 12-month-old pen test reflects a 12-month-old attack surface. Annual testing isn’t a compliance checkbox — it’s the minimum cadence that makes any sense for a changing environment.
What’s the difference between a vulnerability scan and a pen test?
A vulnerability scan identifies known issues using automated tools. A penetration test has a human attempting to actually exploit those vulnerabilities — and finding the ones automated tools miss. A scan tells you what might be wrong. A pen test shows you what an attacker can actually do with it.
How do we know you won’t just break our production environment?
Rules of engagement are agreed in writing before we touch anything. We maintain detailed logs of every action. Critical findings are escalated immediately. Our testers operate with the discipline of practitioners who’ve done this hundreds of times — not junior staff learning on your environment.
How often should I get a pen test done?
Annually as a baseline, plus after any major change — a new application, a cloud migration, a significant infrastructure change. If you're in a regulated industry or handling sensitive data, some frameworks (PCI DSS, for instance) mandate specific intervals regardless of what changed.
What type of pen test do we actually need — network, web app, or something else?
Depends on where your risk sits. If you're a SaaS business, your application is the target. If you've got significant on-prem infrastructure, network testing matters more. Most clients need a mix — we'll scope it based on what you're actually exposed to, not sell you a generic package.
Will this disrupt our staff or operations while it's running?
Testing windows are agreed in advance, and we can schedule around business hours if disruption is a concern. Most engagements run without anyone outside IT noticing — that's the point. Denial-of-service testing, if in scope, is always explicitly called out and scheduled separately.
What do we get at the end — just a list of vulnerabilities?
A written report ranking findings by actual exploitability and business impact, not just a raw scanner output. Each finding includes what we did, what it means for you, and what to fix first. We're also available afterward to walk the technical team through it.
Do you test for social engineering, or just technical systems?
Only if it's in scope — phishing simulations, physical access attempts, and voice-based social engineering are options we can add. Some clients want the human side tested, others just want infrastructure and applications covered. We'll ask before assuming either way.