Not all penetration tests are created equal
There are numerous types of penetration testing. Each type provides different benefits for different types of organizations.
Network vs. Application layer testing
Network layer testing validates that your systems and services, especially public-facing services like web servers and file transfer services, are configured securely, are up-to-date and don’t advertise any obvious low-hanging fruit that would draw an attacker’s attention. Malicious threat actors scan the public internet non-stop for new and critical vulnerabilities. They use this data to launch attacks, often through automated means, then dig further into your network once gaining a foothold.
Application layer testing is where interesting vulnerabilities become newsworthy. Web applications and APIs are difficult to write securely, and the majority of critical vulnerabilities are found here. Testing is much more nuanced and requires experience and skill on the tester’s part to follow complex workflows, identify potential points of entry, and evaluate areas of the application that are most susceptible to attack. This should be followed by manually testing these areas to ensure that code and security checks are operating as intended. Lateral and vertical movement should also be tested to ensure roadblocks are in place for both accessing other users’ data and higher privileged functions, respectively. This often results in critical alerts due to vulnerabilities that could potentially or are actively being exploited by malicious attackers.
Internal vs. External
External testing is the bare minimum when we’re discussing penetration testing and ensures that the perimeter of your network and application is secured without additional inbound routes. This will ensure that external threat actors are unlikely to gain a foothold into your environment.
Internal testing helps to ensure that if you had a threat from an internal actor, disgruntled employee, or someone that was able to breach your external perimeter using social engineering or other method, their impact would be limited. With an internal threat actor already having some legitimate access, this is challenging but it’s important to validate that their access is limited to what’s granted and they are unable or unlikely to elevate to additional privileges that could allow a great impact.
Automated scans vs. Manual testing
Automated scans are important and should be a normal activity in your daily/weekly/monthly security plan and processes. They are often a first step in a penetration test as well. They don’t, of course, replace a penetration test as this activity involves the all-important next steps of manual validation and exploitation to understand what impact any given vulnerability may have in your environment. This also helps you understand what data and access can be gained during the exploitation phase of the test and identify appropriate countermeasures to use to limit this additional incursion.
Tailor your penetration test scope to match the systems and environments in scope for your SOC two report.
How often should you perform a penetration test?
Penetration tests should be conducted at least annually for SOC two environments. It’s also recommended after any significant changes to systems or infrastructure.
Organizations commonly implement a range of system changes to strengthen their security posture, especially when preparing for SOC two audits or remediating issues identified during penetration testing. These changes often include updating network configurations by tightening firewall rules, restricting unnecessary ports, or adding segmentation to isolate sensitive systems.
Many companies also enhance authentication and access controls by enforcing multifactor authentication, implementing single sign‑on, removing dormant accounts, or redesigning roles to ensure least‑privilege access. In addition, teams frequently apply security patches, update outdated software libraries, or upgrade unsupported systems to reduce vulnerability exposure.
Cloud environments often see adjustments such as securing misconfigured storage buckets, enabling encryption, or refining IAM roles. Application-level improvements — like fixing SQL injection flaws, strengthening input validation, or improving session management — are also common outcomes of security testing. Logging and monitoring capabilities may be expanded by increasing log retention, enabling additional audit logs, or integrating systems into a centralized SIEM.
Finally, organizations often harden servers and endpoints by disabling unnecessary services, enforcing encryption, applying CIS benchmarks, or deploying advanced endpoint detection tools, alongside updating supporting policies and procedures to ensure these improvements are sustained over time.
