External Network Penetration Testing

They answer two different questions, and most standards treat them as two separate obligations rather than as alternatives. An external test starts on the internet with nothing. The target is your perimeter: public IP addresses and hostnames, exposed services, remote-access endpoints such as VPN and mail, DMZ services, and the firewall rules that are actually live rather than the ones on the diagram. The question is whether someone can get in. An internal test starts from an assumed breach, with someone already inside. The target is Active Directory, lateral movement, privilege escalation and network segmentation, and the question is how far someone gets once they are in. PCI DSS v4.0.1 draws the same line: Requirement 11.4.2 covers internal penetration testing and Requirement 11.4.3 covers external penetration testing, and satisfying one does not satisfy the other. The two are complements, and buyers frequently run both as a single two-scope engagement.

PCI DSS v4.0.1 Requirement 11.4.3 requires external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, performed by a qualified internal resource or a qualified external third party, with organizational independence of the tester. The standard notes that the tester is not required to be a QSA or an ASV. What it asks for is a defined methodology, a qualified tester, and independence from the systems under test. Our lead tester holds OSCP, credential OS-101-34173, verifiable with the issuer on Credly, which is the kind of evidence an assessor looks for when judging qualification. Two things we are explicitly not, and this page is where a buyer is most likely to assume otherwise. Cybersecify is not a PCI SSC Approved Scanning Vendor, so we cannot perform the quarterly external vulnerability scans that PCI DSS requires an ASV to run, and this service is not an ASV scan. Cybersecify is not a Qualified Security Assessor either, so we cannot conduct your PCI DSS assessment or sign your Report on Compliance. Those two roles stay with your ASV and your QSA. If someone has told you your penetration tester must hold one of those credentials, ask which requirement they are reading, because 11.4.3 does not impose it.

No, and that is the point of the exercise. The test starts where an attacker starts, which is with nothing. What we need from you is written authorisation and the list of public IP addresses and hostnames that belong to you, so that we test your perimeter and nobody else. Where your infrastructure sits with a hosting provider or a cloud platform, we confirm their testing rules before the window opens. Everything after that is discovery: we build the internet-facing inventory ourselves from DNS records, certificate transparency logs and passive sources, because the assets you had forgotten about are usually the ones that matter.

One scope is one internet-facing perimeter: up to 24 public IP addresses and the hostnames resolving to them, including the remote-access endpoints on those addresses such as VPN, mail and DMZ services. Inside that boundary we cover external asset discovery, port and service enumeration on every live host, service version fingerprinting against known vulnerabilities, VPN endpoint configuration and authentication, exposed RDP, SSH and management interfaces, mail perimeter posture including SPF, DKIM and DMARC, DNS configuration, zone transfer and subdomain takeover, TLS configuration and certificate validity on exposed services, credential attack resistance on internet-facing login surfaces, default and weak credentials on edge and network devices, firewall rule and DMZ boundary validation, and the forgotten hosts, staging environments and shadow assets that turn up on almost every perimeter. Out of scope: anything behind the perimeter, which is the internal network test, plus denial-of-service against production, physical attacks, and social engineering or phishing. Additional address ranges and separately managed perimeters are quoted as a custom scoping proposal.

No. A scan lists what is listening and what version each service reports, and it stops there. Much of that list is noise, because a version banner is not a vulnerability until someone has shown that the service is reachable, that the vulnerable code path is enabled, and that the exposure is real. An external network pentest starts from that inventory and then does the part a scanner cannot. We confirm exploitability rather than reporting a banner, we test authentication on your VPN rather than noting that a VPN exists, we chain a weak perimeter service into the access it actually grants, and we tell you what an attacker would reach next. You get a short list of things that are true instead of a long list of things that might be.

One external network scope is 5 business days under the Startup Pentest plan at INR 74,999. A two-scope engagement, most commonly external plus internal network, is 10 business days under the Growth Pentest plan at INR 1,79,999, which adds SOC 2 and ISO 27001 control mapping per finding and a Letter of Attestation signed by the lead tester. Scopes run one after another by default, so each additional scope adds 5 business days: 3 scopes is 15 and 4 is 20. If your deadline is tighter than that, ask us. We can sometimes test several scopes at the same time, which changes the schedule rather than the price, but it depends on the engagement and it is not something we promise up front. Business days are Monday to Friday, and the weekend is a quality buffer that is not counted against the timeline. Both plans include one free retest within one month of the v1.0 report, delivered as v2.0. All prices exclude taxes.

Yes, for the controls a perimeter test genuinely evidences. Under ISO 27001:2022 that is A.8.8 management of technical vulnerabilities and A.8.29 security testing in development and acceptance, plus A.8.20 network security and A.8.22 segregation of networks where a finding lands on the boundary itself. Under SOC 2 that is CC6.6 protection against external threats and CC7.1 vulnerability detection. Every finding comes with reproduction steps, a CVSS v3.1 severity score and remediation direction, and the retest evidences that the fix landed, which is the piece auditors ask for and most reports leave out. What the report is not: Cybersecify is not ISO 27001 or SOC 2 certified itself and does not issue certificates. Your accredited certification body and your CPA firm do that. We produce the technical evidence they ask you to bring.

Four triggers cover most of the engagements we see. A compliance requirement, usually PCI DSS Requirement 11.4.3, a SOC 2 or ISO 27001 audit, or the RBI Directions if you are a regulated entity in India. An enterprise customer or an investor asking for evidence during diligence. A change to the perimeter itself: a new site or office, a new VPN, a cloud migration, a merger that joined two networks, or a firewall rebuild. And fear, usually after a breach at a company that looks like yours. Beyond the trigger, the reason a perimeter test keeps finding things is that perimeters drift. Nobody exposes a service on purpose. It arrives through a temporary firewall rule that was never removed, a staging box that picked up a public address, or a supplier who opened a port for an integration and did not tell anyone.