Question 1

Does an annual penetration test satisfy PCI DSS Requirement 11.4?

Accepted Answer

Yes — and a test after every significant change to the cardholder data environment. PCI DSS 4.0.1 Requirement 11.4 mandates external and internal Penetration Testing at least annually, performed by qualified personnel using a documented methodology. Our engagements are designed to drop straight into the evidence pack: report, methodology reference, tester credentials, and re-test results all in one place.

Question 2

What is a CREST Defensible Penetration Test?

Accepted Answer

CREST DPT is a published specification (currently v5.2) for what makes a penetration test commercially and technically defensible. It covers three things: the firm has appropriate policies and methodology; the people doing the test have appropriate skills, experience and competency; and the firm and the customer agree a defined test specification before work starts. We follow it because procurement and audit teams increasingly ask for it.

Question 3

Vulnerability scanning vs Penetration Testing — what is the difference?

Accepted Answer

A vulnerability scan is mostly automated: it identifies known issues from version banners, signatures and default configurations. A penetration test is mostly manual: it confirms which vulnerabilities are real, chains them together, and demonstrates impact. They serve different purposes. PCI DSS 4.0.1 mandates both — Requirement 11.3 covers scans, 11.4 covers Penetration Testing. Our VAPT engagement combines them in one workstream where scope warrants.

Question 4

How long does a typical penetration test take?

Accepted Answer

Test execution is typically one to three weeks, scope-dependent. A simple external infrastructure test on twenty IPs runs faster than an authenticated web-application test with multiple roles, and a multi-cloud cloud configuration review with exploitation runs longer still. The end-to-end engagement — scoping, planning, testing, reporting and debrief — is usually four to six weeks.

Question 5

Will the test cause downtime or break things?

Accepted Answer

Penetration testing is intrusive by design — exploitation is what distinguishes it from a scan. We work to written rules of engagement that flag any high-impact technique requiring approval before use, and we pause if anything we did not expect happens. Production-environment testing is normal practice; we agree windows for high-impact actions and have a documented escalation path. The risk of incidental impact is real but managed.

Question 6

Do we need to be a customer of yours already?

Accepted Answer

No. Penetration testing is delivered as a stand-alone engagement. A meaningful share of our pen-test work is for customers we have not audited — and a meaningful share of our audit work goes to customers who have used us for testing first. The two services are deliberately decoupled so you are not locked into one because you bought the other.

Question 7

How do you handle critical findings discovered mid-engagement?

Accepted Answer

Critical-severity findings — anything that would let an attacker exfiltrate data, take control of a system, or escalate to administrative privilege — are escalated to your nominated technical contact immediately. We do not wait for the report. The aim is that you can begin remediation while testing continues elsewhere. The report later records what was found, when it was reported, and how you responded.

Question 8

What does the report look like?

Accepted Answer

Every report has the same structure: management summary for non-technical readers, technical findings with severity, evidence and remediation guidance, methodology reference, scope statement, and an appendix of every authenticated test path. Findings are scored on a documented severity scale that maps to CVSS. We avoid CVE-only findings without context — if it is a real risk in your environment we explain why; if not, we say so.

Question 9

Do you also test cloud configurations, or only servers and applications?

Accepted Answer

Yes — cloud is a separate engagement type rather than an extension of infrastructure testing. AWS, Azure and GCP each have their own configuration patterns, identity models and exploitation paths. Cloud engagements include IAM and resource-policy review, network and storage exposure analysis, key-management practice, and where in scope, exploitation against identified weaknesses. We honour the cloud providers' rules of engagement.

Question 10

Is the VAPT redirect from your old site the same service?

Accepted Answer

Yes. Vulnerability Assessment & Penetration Testing has been folded into this page as a featured engagement model — an automated discovery pass followed by manual Penetration Testing of confirmed exposures. The old /vapt URL now redirects here. The methodology references, the deliverables, and the team are the same.

Penetration testing. CREST-aligned. Evidence-led.

What we mean by Penetration Testing

How engagements run

Application & API testing

Infrastructure testing

Cloud configuration testing

Red-team scenario testing

Compliance contexts we cover

PCI DSS 4.0.1

ISO 27001:2022

UK GDPR

NIS-CAF

How a test runs

Scoping call

Authorisation & test plan

Test execution

Report & debrief

Re-test

Engagement types

Why 1 Sequence Cyber

Aligned to the CREST DPT specification

Same firm that runs the audits

Frequently asked questions

Ready to scope a penetration test?