BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: Penetration testing is not a single service. It covers six distinct attack surfaces, each of which requires different methodology, different expertise, and different tooling: external network testing (what attackers can reach from the internet), internal network testing (what an attacker who is already inside can do), web application testing (what an attacker can do through your applications), cloud infrastructure testing (misconfigurations and lateral movement in cloud environments), social engineering testing (what an attacker can achieve by manipulating your people), and red team engagements (multi-vector attacks that test detection and response as well as prevention). Most organizations need more than one type, and the right combination depends on your attack surface, your compliance requirements, and your security program maturity.

Key Takeaways

• Each pen test type covers a distinct attack surface. Selecting the right type or combination requires understanding which attack surfaces represent the most material risk for your organization and which are required by applicable compliance frameworks.
• External network testing is the most common starting point for organizations new to penetration testing because it tests the perimeter that every internet-connected organization exposes. Internal network testing is equally important because it tests what happens after a breach, which is the scenario most organizations are least prepared for.
• Web application testing requires OWASP methodology expertise and is distinct from network testing. An organization that has conducted external network testing has not tested its web applications; the two require different methodology and different expertise to do correctly.
• Cloud infrastructure testing has become a distinct discipline as organizations have moved workloads to AWS, Azure, and Google Cloud. Cloud misconfigurations are consistently among the most significant findings in modern penetration tests, and they require cloud-native testing approaches that general network testers may not be equipped to conduct.
• Red team engagements test detection and response capability, not just vulnerability presence. They are most appropriate for organizations with mature prevention controls that want to validate whether their security operations team would detect and contain a real attack.

External Network Penetration Testing

External network penetration testing simulates an attack from the internet against your internet-facing systems: firewalls, VPN gateways, email servers, web servers, remote access infrastructure, and any other service exposed to the public internet. The tester starts with the same information an external attacker would have, typically the organization’s domain name or IP ranges, and attempts to identify and exploit vulnerabilities that could allow unauthorized access to the internal network or sensitive systems without any prior foothold.

Common findings in external network tests include unpatched software on internet-facing services, misconfigured VPN or remote access systems, exposed administrative interfaces that should not be accessible from the internet, weak or default credentials on externally accessible systems, and SSL/TLS configuration weaknesses that could enable traffic interception. External testing is the most common starting point for organizations conducting their first penetration test because the external perimeter is the attack surface that every internet-connected organization exposes and the starting point for the vast majority of real-world attacks. PCI DSS Requirement 11.4 requires external penetration testing at least once every 12 months. Most other compliance frameworks that require penetration testing include the external perimeter in scope.

Internal Network Penetration Testing

Internal network penetration testing takes an assumed-breach perspective: the tester starts inside the network, simulating an attacker who has already gained a foothold through phishing, a compromised external-facing service, or a rogue insider. The test evaluates how far an attacker could move through the internal environment, what systems and data they could reach, and whether the network segmentation, access controls, and monitoring that the organization relies on would limit the attacker’s progress.

Internal network tests consistently produce findings that surprise organizations because most security investment is directed at the perimeter rather than at limiting damage after a perimeter breach. Common findings include flat network architectures with no segmentation between user workstations and sensitive servers, Active Directory misconfigurations that allow privilege escalation from a standard user account to domain administrator, service accounts with excessive privileges that can be exploited for lateral movement, and monitoring gaps that would allow an attacker to move through the environment for days or weeks without triggering an alert. For organizations that believe they are secure because their perimeter is well defended, an internal network test often provides the clearest picture of their real post-breach exposure. The monitoring gaps these tests surface are also the strongest argument for pairing prevention with detection through endpoint detection and response, which is what catches the lateral movement an internal test demonstrates.

Web Application Penetration Testing

Web application penetration testing evaluates the security of applications accessible through a browser, covering the OWASP Top 10 and the broader range of application-specific vulnerabilities that automated scanners and network-level testing do not reach. The methodology is aligned to the OWASP Testing Guide and covers authentication (can an attacker log in as another user or bypass authentication entirely), authorization (can a logged-in user access data or functionality they should not be permitted to), session management (can an attacker hijack or forge a session), injection (can an attacker manipulate database queries, commands, or other interpreters through application inputs), and business logic (can the application be manipulated to perform actions its designers did not intend).

Business logic testing is where manual penetration testing most clearly exceeds what automated scanning can provide. A scanner can identify SQL injection vulnerabilities by sending known payloads and observing responses. It cannot reason about how an e-commerce application’s checkout process is supposed to work and probe for ways to manipulate it to apply unauthorized discounts, skip payment steps, or access other users’ order history. A human tester can, and business logic flaws in customer-facing applications are consistently some of the most significant findings in web application penetration tests, both because of their exploitability and because of the direct business and regulatory impact of an attacker manipulating core application functions. This is the same manual-versus-automated distinction that separates penetration testing from vulnerability scanning across every test type.

Cloud Infrastructure Penetration Testing

Cloud infrastructure penetration testing evaluates the security of environments running on AWS, Azure, Google Cloud, or hybrid cloud configurations. Cloud testing requires a different methodology from traditional network testing because cloud environments are managed through APIs and identity and access management systems rather than traditional network protocols, and because the most common and impactful cloud vulnerabilities are configuration issues rather than software vulnerabilities.

Common findings in cloud penetration tests include overly permissive IAM roles that allow privilege escalation from a limited-access account to broad administrative access, publicly exposed storage buckets or blob containers containing sensitive data, misconfigured security groups or network access control lists that expose services that should be internal, unused access keys with excessive permissions attached to service accounts, and insufficient logging and monitoring configuration that would leave lateral movement through the cloud environment undetected. Organizations that have migrated workloads to cloud environments without specifically testing those environments are carrying cloud-specific exposure that their traditional network penetration testing has not evaluated.

Social Engineering and Phishing Testing

Social engineering penetration testing evaluates the human attack surface: the degree to which employees can be manipulated into disclosing credentials, clicking malicious links, opening malicious attachments, or taking other unsafe actions that give an attacker a foothold. Phishing simulations send targeted email messages designed to appear legitimate and measure how many employees click the link or provide credentials. Vishing tests involve phone-based social engineering, with testers calling employees and attempting to obtain information or access through impersonation. Physical social engineering tests attempt to gain unauthorized physical access to facilities through techniques such as tailgating, impersonation, or pretext.

Social engineering testing is structured to measure and improve resilience, not to embarrass employees. Employees who click on phishing simulations are identified for targeted training, not punished for failure. The aggregate results of the campaign measure the organization’s overall phishing susceptibility rate, which is a meaningful metric for tracking security awareness program effectiveness over time. Most organizations find that their phishing susceptibility rate is higher than they expected, and that certain departments or roles, typically finance, HR, and executive assistants, are disproportionately targeted and susceptible.

Red Team Engagements

Red team engagements are extended, multi-vector adversarial simulations that go beyond testing for the presence of vulnerabilities to testing the organization’s detection and response capability. A red team operates covertly, attempting to achieve a defined objective (such as accessing a specific system, exfiltrating specific data, or compromising specific accounts) without being detected by the organization’s security operations team. Success in a red team engagement is not measured solely by whether vulnerabilities are found; it is measured by whether the blue team detected the attack, how quickly, and how effectively they contained it.

Red team engagements are most appropriate for organizations with mature security programs that have already addressed the most significant vulnerability classes through prior penetration testing. If the organization has known critical vulnerabilities, a red team engagement will find and exploit them, but the value of the engagement comes from the covert multi-vector simulation and the detection and response evaluation, not from the vulnerability discovery alone. Organizations that conduct red team engagements before establishing baseline security hygiene will find that the red team spends its time exploiting well-known vulnerability classes rather than testing the more sophisticated detection and response capabilities the engagement format is designed to evaluate.

Armour Cybersecurity conducts all six test types with OSCP-certified consultants, methodology aligned to PTES, OWASP, and NIST SP 800-115 as appropriate, and findings structured for direct use in compliance audits. To discuss the right scope for your environment and compliance requirements, visit the penetration testing service page.

Frequently Asked Questions

Which penetration test type should we start with?

For most organizations conducting their first penetration test, the external network test is the right starting point because it covers the attack surface that every internet-connected organization exposes and is the scope most commonly required by compliance frameworks at initial certification. The internal network test is the logical second engagement because it tests the post-breach scenario that is statistically most likely to produce significant business impact. If the organization operates customer-facing web applications, web application testing should be included in the initial scope or conducted in parallel with the network tests, because web application vulnerabilities are a distinct attack surface that network testing does not cover. Cloud testing should be included whenever significant workloads run in cloud environments. Social engineering is a valuable addition to any initial scope because it tests the human attack surface that technical controls cannot address.

Can we combine multiple test types into a single engagement?

Yes, and combining test types into a coordinated engagement often produces more realistic findings than running them separately. An external network test combined with a web application test covers both the infrastructure perimeter and the application attack surface in a single coordinated scope. A social engineering test combined with an internal network test can simulate the most realistic attack scenario: the social engineering test establishes the initial foothold through phishing, and the internal network test evaluates how far an attacker can move after gaining that foothold. The scoping conversation with the penetration testing provider is where the right combination of test types is defined based on the organization’s specific attack surface, risk priorities, and compliance requirements.

What is API penetration testing and when do we need it?

API penetration testing evaluates REST, GraphQL, and gRPC APIs for security weaknesses specific to API design and implementation. Modern applications are heavily API-dependent, and APIs present a distinct set of vulnerabilities from those found in browser-based web applications. The OWASP API Security Top 10 defines the most critical API vulnerability categories, including Broken Object Level Authorization (BOLA), where an API exposes data objects to users who should not have access to them; Broken Function Level Authorization (BFLA), where an API allows users to invoke functions they should not be permitted to call; and Excessive Data Exposure, where an API returns more data than the consuming application displays, leaving sensitive fields accessible to anyone who can inspect the API responses directly. Any organization whose applications rely on APIs, which is most modern organizations, should include API testing when their application penetration testing scope is defined.

What is a purple team exercise and how is it different from a red team?

A purple team exercise is a collaborative engagement in which the offensive team (red) and the defensive team (blue) work together rather than in opposition. In a traditional red team engagement, the offensive team operates covertly and the defensive team is not informed of the engagement; the test measures whether the blue team can detect and respond to an attack they do not know is happening. In a purple team exercise, the offensive team executes specific attack techniques transparently while the defensive team observes and validates whether their detection and response tools and processes catch each technique. Purple team exercises are designed to improve defensive capability through guided, real-time testing rather than to measure detection capability through covert simulation. They are most appropriate for organizations that want to tune and validate their SIEM, EDR, and incident response processes against specific attack techniques without the overhead of a full covert red team engagement.

How do compliance frameworks specify what type of penetration testing is required?

Compliance frameworks vary in how specifically they define penetration testing scope requirements. PCI DSS Requirement 11.4 is among the most prescriptive: it requires both external and internal penetration testing, testing of network layer segmentation controls, and application layer testing for organizations in scope for PCI DSS. SOC 2 does not prescribe specific penetration testing types but expects evidence of penetration testing as a separate evaluation under the CC4.1 monitoring criterion, with findings also supporting the CC7 series on vulnerability detection and response. ISO 27001 does not name penetration testing as a standalone control; it flows from the risk assessment, and testing commonly supports Annex A control A.8.8 (Management of technical vulnerabilities), with scope appropriate to the organization’s risk. HIPAA requires a technical evaluation of whether security controls are meeting the Security Rule, which auditors typically expect to include penetration testing of systems handling protected health information. The scoping conversation with your penetration testing provider should include a review of your compliance requirements to ensure the scope satisfies all applicable framework obligations.

The Bottom Line

Penetration testing is not one service, it is six, and they are not interchangeable. External network testing covers the perimeter every organization exposes; internal network testing shows what happens after a breach; web application testing finds the business logic and authorization flaws no scanner reaches; cloud testing catches the misconfigurations that come with AWS, Azure, and Google Cloud; social engineering tests the human attack surface; and red team engagements test whether your security operations team would actually detect and contain a real attack. Most organizations need a combination, sequenced to their maturity: external and internal first, web application and cloud where those surfaces exist, social engineering to measure human risk, and red team once the fundamentals are solid. The right scope is driven by your actual attack surface and your compliance obligations, not by a one-size package. Armour Cybersecurity conducts all six types with OSCP-certified consultants and methodology aligned to PTES, OWASP, and NIST SP 800-115, with reports built for the audit and the engineers. To scope the right combination, visit the penetration testing service page.