How to map your attack surface before a pentest

A penetration test is only as thorough as the preparation behind it. If you hand a pentester an incomplete or poorly defined scope, you will get results that reflect that gap, critical assets left untested, findings that miss the real risk, and remediation work that addresses the wrong problems. Mapping your attack surface before testing begins is the step that changes all of that. This guide walks you through exactly how to do it, from cataloguing your assets to validating the final map so your pentest covers what actually matters.

Gather your assets before mapping begins

Before you can map anything, you need a complete inventory of what your organization owns, operates, and depends on. This sounds straightforward, but in practice most organizations discover forgotten assets, shadow IT, or inherited infrastructure during this phase. Start wide and narrow down later.

1. Pull a list of all registered domains and subdomains your organization controls, including legacy domains that may still resolve.
2. Document all IP ranges, both static and dynamic, assigned to your organization, including cloud-allocated ranges.
3. List all third-party services, SaaS platforms, and APIs that connect to your internal systems or handle your data.
4. Include hardware assets: servers, network devices, endpoints, and any operational technology or IoT devices on the network.
5. Check your DNS records, SSL certificate transparency logs, and cloud provider dashboards to surface assets that may not appear in internal documentation.

After completing this step, you should have a working asset register, even a rough spreadsheet is enough at this stage. If you find assets you did not know existed, that is a good sign you are doing this correctly. Those surprises are exactly what attackers look for.

Identify your external-facing entry points

External entry points are the assets visible and reachable from the internet. These are the first targets any attacker will probe, which makes them the highest priority for your attack surface map. Work through your asset register and flag every item that is internet-accessible.

1. Run passive reconnaissance using tools like Shodan, Censys, or similar search engines to see what your organization exposes publicly.
2. Enumerate open ports and running services on external IP addresses using a port scanner such as Nmap.
3. Identify all web applications, login portals, APIs, and remote access interfaces (VPN gateways, RDP, SSH) reachable without internal network access.
4. Check for exposed cloud storage buckets, misconfigured cloud services, or publicly accessible admin panels.
5. Document any third-party integrations that create an inbound connection into your environment.

Once you have worked through this list, map each entry point to the asset it belongs to and note what service or application is running behind it. This creates the foundation your pentester will use to begin external testing. If you find services that should not be public, remove or restrict them before the test, there is no value in paying to confirm an obvious misconfiguration you can fix today.

Map internal attack paths and lateral movement risks

External entry points get attackers in the door. Internal attack paths determine how far they can go once inside. This step requires you to think like an attacker who has already breached the perimeter and is now looking for ways to move laterally toward sensitive data or critical systems.

Network segmentation and trust relationships

Review how your internal network is segmented. Flat networks, where any device can communicate with any other device, represent a significant lateral movement risk. Document which network segments exist, what they contain, and whether access controls between segments are enforced. Pay particular attention to trust relationships: systems that automatically authenticate each other or share credentials are prime targets for lateral movement.

Privileged accounts and credential exposure

Map where privileged accounts exist and which systems they can access. Service accounts, shared admin credentials, and accounts with domain-wide permissions create paths that attackers exploit to escalate access quickly. Note any systems where credentials are stored in plaintext, scripts, or configuration files, these are common findings in penetration testing engagements and represent high-value targets.

After completing this step, you should have a rough diagram or documented list showing how an attacker could realistically move from an initial compromise point toward your most sensitive assets. This internal map is as important as the external one.

Prioritize high-risk areas for pentest scope

Not every asset carries equal risk, and a well-scoped penetration test focuses effort where it matters most. Use the information gathered in the previous steps to rank areas by their potential impact if compromised.

1. Identify your crown jewels: the data, systems, or services whose compromise would cause the most damage, financial, operational, or reputational.
2. Cross-reference crown jewels with the attack paths you mapped. Assets that are both high-value and reachable through multiple paths deserve the highest priority.
3. Flag any compliance-relevant systems, those storing personal data, financial records, or subject to regulatory requirements, as mandatory inclusions in the pentest scope.
4. Deprioritize assets that are well-isolated, have limited access to sensitive data, and have already been tested recently with no significant findings.

The output of this step is a prioritized scope list. Share this with your pentesting team before testing begins so they allocate time and effort proportionally. A focused, well-prioritized scope produces more actionable findings than a broad, shallow test that touches everything briefly.

Validate and update the map before testing starts

An attack surface map is only useful if it reflects reality at the moment of testing. Infrastructure changes, new deployments, and configuration updates happen constantly, and a map built three months ago may already be outdated. Build a validation step into your process before the pentest kicks off.

1. Review the asset register one final time and confirm that all domains, IPs, and services are still active and correctly categorized.
2. Verify that any assets removed from scope are genuinely inaccessible, not simply unlisted.
3. Confirm with your IT or infrastructure team that no major changes are planned during the testing window, as these can interfere with results.
4. Share the finalized map with your pentesting team and align on scope boundaries, out-of-scope systems, and rules of engagement.

Once validated, document the map formally and treat it as a living record. The same process you have just completed should be repeated before every future engagement, and ideally maintained on an ongoing basis as your environment evolves. If you want expert support building and maintaining your attack surface inventory, contact us to discuss how we can help you stay ahead of what attackers will find.

Related Articles

• How much security is enough for a scale-up?
• How do you justify a pentest budget to your CFO?
• How does vulnerability scanning support digital transformation?
• Should you outsource vulnerability scanning services?
• What is vulnerability scanning used for?