Network penetration testing assesses the security of approved internet-facing systems, internal networks and network separation. Balhence scopes the access paths that matter to your team, validates findings within agreed operational limits, and provides evidence and practical remediation. Remote engagements are available for India and US teams; access arrangements and specialist requirements are confirmed before work begins.
Agree where testing starts and which systems it may reach. An external assessment, an internal assessment and a segmentation check answer different questions.
| Workstream | Assessment focus | Scope information |
|---|---|---|
| External network pentest | Internet-facing services, remote access controls and exposed configuration. | Approved public IPs, hostnames, ownership and service providers. |
| Internal network pentest | Access paths between approved hosts, identity boundaries and privilege controls. | Live hosts, sites, segments, test identities and the starting access level. |
| Network segmentation testing | Whether agreed zones permit only the connections your policy allows. | Source and destination zones, expected traffic rules and a testing position in each source zone. |
A scan helps inventory services and identify possible weaknesses. A penetration test adds manual validation and evaluates security boundaries within the agreed scope. The report separates confirmed impact from unverified observations. An IP count alone does not describe the depth of either assessment.
Cloud-hosted networks may need cloud penetration testing for account permissions, storage and workload controls. Application workflows need their own web application testing or API testing scope.
Share an inventory and diagram before scheduling. Keep passwords, tokens and sensitive architecture files out of the public enquiry form; access is arranged through an agreed channel.
Name IP addresses or CIDR ranges, estimated live hosts, locations, network devices and identity domains. Mark customer-controlled systems, third-party dependencies and exclusions. A broad address range can contain systems that must remain outside the test.
Confirm VPN arrangements, permitted test locations, working test accounts and required routing. For internal or segmentation work, identify the starting network position and reachable zones. A restricted VPN can limit what the assessment can establish.
Provide intended access between zones, administrative interfaces and identity services. Include role expectations and permitted authentication methods. Credential testing requires explicit approval, account-lockout safeguards and agreed attempt limits.
Identify sensitive appliances, legacy hosts, critical services and operational dependencies. Wireless, OT or ICS, physical access and social engineering require separate explicit scope. Specialist availability and safety requirements are confirmed before acceptance.
Written rules define the authorized assets, approved techniques, testing windows and operational limits. The plan names a technical contact, escalation channel and stop conditions.
Agree request rates, account limits, excluded services and acceptable evidence. Coordinate with the teams monitoring the network. Destructive testing, denial of service and disruptive credential activity are excluded; unavailable checks are recorded as limitations.
Confirm impact with bounded evidence and controlled accounts where practical. We do not collect customer data simply to strengthen a finding. When validation would exceed the agreed limits, the report explains the observation and what remains unconfirmed.
When network, cloud and application testing overlap, the proposal identifies shared discovery and findings once. Additional testing depth is described separately so the same issue is not charged twice. NIST SP 800-115 is a public reference for planning technical security assessments; the agreed scope determines this engagement's coverage.
The report explains the tested access paths, confirmed issues and coverage limits. A good penetration testing report should give infrastructure owners enough context to choose and verify a fix.
We agree reporting format, review meetings and any re-test before scheduling.
Confirm scope, access and reporting before reserving the testing window.
The agreement identifies external hosts, internal networks, identity services and segmentation paths to assess. Coverage depends on access, operational constraints and the agreed testing depth. Wireless, operational technology, social engineering and physical security require separate explicit scope.
Live hosts, sites, network segments, identity environments and access requirements determine effort. Reporting, coordination and re-test requirements also affect the quote. Share a current inventory and the decisions the assessment must support so we can confirm a realistic scope.
Production testing needs agreed windows, operational contacts, request limits and stop conditions. Identify fragile systems before work starts. We confirm what can be validated safely and document any checks that cannot be completed under those constraints.
Only when those workstreams are explicitly included. Network exposure does not cover every cloud permission, web workflow or API authorization rule. We define shared coverage once and explain any additional depth in the proposal.
The agreement states whether a re-test is included, its timing and which findings it covers. A re-test checks the agreed fixes and records their status. New hosts, significant changes or additional testing depth may require a revised scope.
Tell us the workstream, approximate live hosts, sites and deadline. For remote delivery, see our India services or US services.