Offensive Cybersecurity FAQ

Offensive cybersecurity uses authorized testing to identify and validate security weaknesses before real attackers can exploit them. It can include both automated and human-led techniques, such as vulnerability scanning, penetration testing, red teaming, application security testing, AI security testing, and testing of physical devices to include IoT and medical devices.

The goal is to uncover weaknesses, determine which ones present meaningful risk, and provide clear, practical guidance for reducing that risk.

Yes. Internal penetration testing evaluates what an attacker could access or accomplish after gaining a foothold inside the organization’s network. This may simulate a compromised employee workstation, stolen credentials, a malicious insider, or an attacker who has bypassed perimeter defenses.

Internal testing is commonly performed remotely through a VPN connection into the client environment. In some cases, the testing team may use a dedicated test system or virtual machine placed on the internal network to provide the appropriate level of access and visibility.

Testing commonly includes internal systems, network services, Active Directory, authentication and access controls, segmentation, privilege escalation, lateral movement, and access to sensitive data or critical systems.

Internal penetration testing helps identify weaknesses that may not be visible from the Internet and shows how far an attacker could move through the environment after the initial compromise.

Application security testing examines how a web application, API, or mobile application protects its users, data, and business functions. Testing can cover authentication, authorization, session handling, input validation, sensitive data exposure, business logic, and other application-specific security controls.

Testing may be performed unauthenticated, authenticated, or as a combination of both. Unauthenticated testing evaluates what an attacker can access or exploit without valid credentials. Authenticated testing provides one or more test accounts so the tester can evaluate functionality available after login, including access controls, privilege boundaries, user roles, session management, and business workflows.

Authenticated testing generally provides broader and deeper coverage because many important application vulnerabilities are only reachable after login. It also allows testers to compare permissions between different user roles and identify issues such as horizontal or vertical privilege escalation. Because this approach requires more test accounts, workflows, and manual validation, it typically requires more testing time and therefore costs more than unauthenticated-only testing.

Manual testing is particularly valuable for access-control weaknesses, complex workflows, and business-logic flaws that automated tools may not reliably identify.

AI security testing evaluates how an AI application and its connected systems behave under adversarial conditions. For generative AI and AI agents, testing can cover prompt injection, sensitive data exposure, unsafe output handling, and unauthorized tool actions. Scope should include the model’s access to data, APIs, retrieval sources, and business workflows—not just chatbot responses.

See the OWASP Gen AI Red Teaming Guide for additional context.

Medical device security testing evaluates whether a device and its supporting ecosystem can withstand realistic cyberattacks without compromising patient safety, sensitive data, or device functionality. Testing may include the device itself, embedded software and firmware, network and wireless interfaces, authentication, local storage, update mechanisms, APIs, mobile or web applications, and communications with supporting cloud services.

For manufacturers preparing an FDA premarket submission, penetration testing can help demonstrate that cybersecurity controls are effective against current threats and provide supporting evidence for the device’s cybersecurity risk assessment. FDA guidance specifically identifies penetration testing as an important part of evaluating the security of connected and software-enabled medical devices.

Testing may also be performed throughout the product lifecycle to identify newly introduced vulnerabilities, validate security updates, and support ongoing vulnerability-management activities after the device has entered the market.

Remediation testing, or retesting, checks whether fixes resolve previously reported vulnerabilities. Testers repeat relevant checks and assess whether the original attack path still works. Results should identify which findings are resolved, partially resolved, or still open. 

Retesting is usually limited to the findings from the original assessment rather than repeating the entire penetration test. Whether retesting is included in the original fee, charged separately, or subject to a completion deadline varies by provider and should be confirmed before the engagement begins. If significant time has passed or the environment has materially changed, a new assessment may be more appropriate than a limited retest.

Penetration testing and red teaming use many of the same offensive security techniques, but they differ mainly in scope and how constrained the testing is.

A penetration test is performed against a clearly defined scope with specific rules of engagement. The tester focuses on designated systems, applications, networks, or technologies and attempts to identify and exploit weaknesses within those boundaries.

A red team assessment is typically more open-ended and objective-driven. Instead of limiting testing to a narrow technical scope, the red team may use multiple attack paths across the organization including technical attacks, social engineering, physical access, or other approved techniques to determine whether it can achieve a defined objective.

In short, penetration testing asks “What can be compromised within this defined scope?” while red teaming asks “What is the most effective path an attacker could use to compromise the organization and achieve the objective?”

Red, blue, and purple teams have different roles in testing and improving an organization’s security defenses.

• Red teams simulate realistic attackers and attempt to achieve defined objectives while avoiding or bypassing security controls.
• Blue teams defend the environment by monitoring for threats, investigating suspicious activity, and responding to attacks.
• Purple teaming brings offensive and defensive teams together so they can test specific attack techniques, measure whether defenses detect them, and improve security controls based on the results.

Red teaming focuses on adversary simulation, blue teaming focuses on defense, and purple teaming focuses on collaboration and improving detection and response.

Yes. Where PCI DSS Requirement 11.4 applies, organizations must perform internal and external penetration testing, and vulnerability scanning alone does not satisfy the requirement. The testing methodology must include both network-layer and application-layer penetration testing, cover the cardholder data environment and critical systems, and address segmentation controls where segmentation is used to reduce PCI scope.

PCI penetration testing is not intended to be a fully automated exercise. PCI Security Standards Council guidance describes penetration testing as essentially a manual endeavor, with automated tools used to assist discovery and repetitive testing rather than replace tester judgment. Simply running an automated vulnerability or exploitation tool does not satisfy the penetration-testing requirement. 

For in-scope web applications, the penetration test must include application-layer testing for the vulnerability classes identified by PCI DSS Requirement 6.2.4, including attempts to bypass or abuse authentication, authorization, and access-control mechanisms. PCI SSC guidance strongly encourages organizations to provide credentials for the application's defined user roles so testers can evaluate authenticated functionality, privilege boundaries, and whether one user or role can access data or functions belonging to another.

Penetration testing must also be repeated at the required frequency, typically at least annually, and after applicable significant changes, with exploitable findings remediated and retested. The exact validation obligations depend on the organization's PCI scope and reporting method, such as the applicable SAQ or ROC.

SOC 2 does not prescribe a specific penetration-testing frequency or require a penetration test in every case. However, penetration testing is commonly used to support the Security Trust Services Criteria by validating technical safeguards, identifying exploitable vulnerabilities, and demonstrating that security risks are being evaluated and addressed.

A well-documented penetration test can also provide useful evidence during a SOC 2 audit by showing the scope of testing performed, identified findings, remediation activities, and retesting results.

Start with the business question you need answered: which systems are exploitable, whether defenses detect an attacker, or whether a new application or AI workflow is safe to deploy. Agree on scope, authorization, test accounts, timing, and deliverables before testing. A useful report explains validated findings, business impact, recommended fixes, and retesting options.

Explore HighViz Security services or schedule a scoping conversation.

Scoping starts by defining what needs to be tested, why it is being tested, and what level of coverage is required. The scope may include external or internal networks, web or mobile applications, cloud environments, APIs, wireless systems, devices, or other technologies.

The testing team then works with the organization to identify in-scope assets, testing objectives, access requirements, timing restrictions, sensitive systems, and any activities that should be excluded. These details are documented in the scope and rules of engagement so both sides understand exactly what testing is authorized.

A well-defined scope should be broad enough to evaluate meaningful risk while remaining focused enough to provide thorough testing within the available time and budget.