What Is PENTEST? A guide to system Penetration Testing for businesses
- Thanh Hoang
- Aug 5
- 13 min read
PENTEST, short for Penetration Testing, is a controlled security assessment that simulates real-world attack techniques to determine whether weaknesses in applications, APIs, network infrastructure, user accounts, or security configurations can be exploited and cause actual business impact.
In Vietnam, this activity is also commonly described as system penetration testing, security penetration testing, or system intrusion assessment.
The key difference between PENTEST and basic vulnerability detection is that a company does not receive only a list of technical issues. A useful penetration test should help answer business-critical questions:
Where could an attacker gain initial access?
Which weaknesses can actually be exploited?
Can multiple minor weaknesses be combined into an attack chain?
Which systems, accounts, data, or business processes could be affected?
What should the technical team remediate first?
Have the implemented fixes actually resolved the risk?
A complete PENTEST programme usually follows this journey:
Define objectives → Select the scope → Prepare the assessment → Perform controlled exploitation → Report and remediate → RetestPENTEST is therefore not only a technical exercise. For Vietnamese companies, foreign-invested enterprises, and organisations operating systems or processing data in Vietnam, it can also support risk management, supplier assessment, customer assurance, regulatory readiness, and verification of existing security controls.
1. What is PENTEST?
According to NIST, penetration testing is a security testing activity used to assess the extent to which a system, device, or process can resist active attempts to compromise its security. NIST SP 800-115 also places penetration testing within a broader process that includes planning, conducting technical tests, analysing findings, and developing mitigation strategies.
In practice, the testing team may use methods and techniques similar to those used by real attackers. However, every action must remain within a predefined and authorised scope.
A properly governed PENTEST should include at least:
Written authorisation to conduct the test.
A clearly defined list of in-scope assets.
Systems and techniques that are explicitly excluded.
A defined start and end time.
Stop conditions.
Emergency contact points.
Rules for collecting, storing, transmitting, and deleting data.
An escalation process for critical findings.
PENTEST does not mean attempting to compromise a system as deeply as possible. The testing team should create enough evidence to demonstrate the risk without accessing or copying more data than necessary.
What can PENTEST not prove?
PENTEST cannot prove that a system is completely secure.
The results reflect only:
Assets included in the agreed scope.
The state of the environment during the testing period.
Accounts and information provided to the testing team.
Techniques authorised by the organisation.
The time and resources allocated to the engagement.
PENTEST also does not replace:
Continuous vulnerability scanning.
Patch management.
A secure software development lifecycle.
SOC or MDR monitoring.
Identity and access management.
Backup and disaster recovery.
Incident response and digital forensics.
A complete compliance assessment.
After a major change to an application, infrastructure, Cloud environment, identity system, or access model, previous PENTEST results may no longer accurately represent the current security posture.
2. How is PENTEST different from Vulnerability Scanning, Security Audits, and Red Teaming?
These terms are often used interchangeably, even though they have different objectives and expected outcomes.
Activity | Primary question | Typical method | Common output |
Vulnerability scanning | Are there signs of known vulnerabilities? | Primarily automated tools | A list of alerts and affected assets |
Vulnerability assessment | Which vulnerabilities exist and should be prioritised? | Tools combined with expert validation | Analysed and prioritised findings |
PENTEST | Can weaknesses be exploited, and what impact could they cause? | Controlled attack simulation | Evidence, attack paths, and remediation guidance |
Security audit | Does the system meet a defined policy, standard, or requirement? | Review of documentation, configuration, and controls | Compliance gaps or control deficiencies |
Red Team exercise | Can the organisation detect and stop a realistic attack campaign? | Broader adversarial simulation | Findings on prevention, detection, and response |
A vulnerability scanner may identify outdated software, exposed services, or insecure configurations. However, automated tools often cannot fully evaluate business logic flaws, complex authorisation weaknesses, attack chains, or the practical impact of a finding in a specific environment.
PENTEST goes further by validating exploitability.
For example, an authorisation flaw may allow a customer from Company A to access data belonging to Company B. This issue may not be clearly identified by an automated scanner, but it can create a serious data protection and contractual risk.
In contrast, a vulnerability with a high technical severity score may not be exploitable if the affected feature is disabled, the asset is not reachable, or effective mitigating controls are already in place.
Businesses can explore this distinction further in IPSIP’s article on the difference between penetration testing and vulnerability scanning.
3. Which systems can a business PENTEST?
The scope should be based on assets, data, business processes, and realistic risk scenarios. It should not be defined only by the number of IP addresses or URLs.
3.1. Web Applications
Web Application PENTEST commonly evaluates:
Authentication.
Session management.
Authorisation.
Input handling.
File upload functions.
Business logic.
Transactions.
Third-party integrations.
Unauthorised data access.
The OWASP Web Security Testing Guide is one of the most widely recognised references for testing web applications and web services.
3.2. APIs
API PENTEST is particularly relevant to SaaS platforms, mobile applications, partner integrations, and microservices architectures.
The scope may include:
API authentication.
Token management.
Object-level authorisation.
Function-level authorisation.
Rate limiting.
Data exposure.
Transaction logic.
Automated abuse of legitimate functions.
3.3. Mobile Applications
Mobile Application PENTEST may assess:
Data stored on the device.
Communication with APIs.
Session handling.
Protection of credentials.
Deep links.
Update mechanisms.
Resistance to application tampering.
Businesses developing digital products can review IPSIP’s penetration testing services for web and mobile applications.
3.4. External Network Infrastructure
External Network PENTEST evaluates assets that may be reachable from the Internet, including:
Servers.
VPN systems.
Firewalls.
Network devices.
Management interfaces.
Remote-access services.
Email and collaboration systems.
The objective is to determine what access paths may be available to an external attacker without an internal account.
3.5. Internal Networks and Active Directory
Internal PENTEST often begins with the assumption that an internal account or device has already been compromised.
The testing team may evaluate:
Network segmentation.
Password and authentication policies.
Service accounts.
Excessive privileges.
Privilege-escalation paths.
Lateral movement.
Active Directory configuration.
Access to critical servers and data.
3.6. Cloud Environments
Cloud PENTEST should not be understood simply as scanning servers hosted on AWS, Microsoft Azure, or Google Cloud.
The assessment may cover:
Identity and Access Management.
Storage resources.
Security groups and network configurations.
Secrets and access keys.
Containers and workloads.
CI/CD pipelines.
Serverless services.
Managed Cloud services.
The shared-responsibility boundary between the organisation and the Cloud provider.
Businesses operating Cloud workloads can explore IPSIP’s Cloud penetration testing services.
3.7. AI Systems
When a business integrates AI agents, chatbots, or large language models into its operations, new attack surfaces may emerge, including:
Prompt injection.
Unauthorised access to knowledge bases.
Abuse of connected tools.
Data leakage through model outputs.
Excessive AI-agent privileges.
Interaction with internal APIs.
Automated actions beyond the original business purpose.
AI system PENTEST requires a specialised methodology and cannot rely only on traditional web application checklists.
More detail is available in IPSIP’s article on PENTEST for AI systems.
Businesses that have not yet identified the right scope can use IPSIP’s PENTEST selection matrix.
4. What is the difference between Black-Box, Grey-Box, and White-Box PENTEST?
These models describe how much information and access the organisation provides to the testing team.
4.1. Black-Box PENTEST
The testing team receives very little initial information and approaches the environment in a way that resembles an external attacker.
This model is suitable when the organisation wants to assess:
Its public attack surface.
Asset discoverability.
Risks from an unauthenticated position.
The effectiveness of external security controls.
One limitation is that part of the engagement will be spent discovering information and identifying assets.
4.2. Grey-Box PENTEST
The testing team receives partial information or accounts representing specific user roles.
Grey-box testing is often suitable for:
Authorisation testing.
Business logic testing.
Customer portals.
SaaS platforms.
Applications with multiple user roles.
Authenticated APIs.
This approach often provides a practical balance between realism and coverage.
4.3. White-Box PENTEST
The testing team receives more detailed information, which may include:
Architecture documentation.
Accounts for multiple user roles.
Data-flow diagrams.
Configuration details.
Source code or API documentation.
White-box testing allows specialists to focus more time on depth rather than rediscovering information already known by the organisation.
No single model is always superior. The right choice depends on the business question the organisation wants the PENTEST to answer.
5. How is a PENTEST conducted?
5.1. Define the Business Objective
The objective should be more specific than “find vulnerabilities”.
The organisation should determine:
Which assets need protection?
Which attack scenarios are most concerning?
What event or decision is the assessment supporting?
Will the results be used for technical remediation, governance, customer assurance, or compliance?
For example, the objective may be to test unauthorised access to customer data, identify privilege-escalation paths, or validate security before launching a new platform.
5.2. Define the Scope
The scope may include:
Domains.
IP addresses.
Applications.
APIs.
Test accounts.
Mobile applications.
Cloud subscriptions.
Active Directory domains.
Network segments.
Excluded assets must also be documented clearly.
5.3. Agree on the Rules of Engagement
The Rules of Engagement govern how the PENTEST will be conducted.
They should define:
Testing windows.
Permitted techniques.
Prohibited techniques.
Exploitation limits.
Rules for testing production environments.
Stop conditions.
Emergency communication channels.
Data-handling requirements.
Escalation procedures for critical findings.
This is especially important for foreign-invested enterprises, where approval may involve headquarters, the Vietnam IT team, regional security teams, Cloud administrators, and application owners in other countries.
5.4. Prepare the Required Inputs
Depending on the testing model, the organisation may need to provide:
An asset inventory.
System owners.
User accounts for different roles.
API documentation.
Architecture or data-flow diagrams.
Approved IP addresses.
Staging or production environments.
Maintenance windows.
Relevant monitoring systems.
Emergency contacts.
IPSIP’s PENTEST preparation checklist can help IT teams avoid delays, missing accounts, and scope confusion.
5.5. Collect Information and Map the Attack Surface
The testing team identifies the systems, services, user roles, interfaces, and data flows relevant to the assessment objective.
5.6. Identify and Validate Weaknesses
Automated tools may be used to improve coverage, but results must be analysed by specialists.
Business logic flaws, authorisation weaknesses, and attack chains usually require manual testing.
5.7. Perform Controlled Exploitation
The testing team creates enough evidence to validate the risk without accessing systems or data beyond what is necessary.
If a critical issue is discovered, the agreed escalation process should be used instead of waiting until the final report.
5.8. Analyse the Impact
Each finding should be evaluated in the context of:
The affected asset.
Required access.
Reproducibility.
Related data.
Attack chains.
Operational impact.
Customer and contractual impact.
5.9. Produce the Report
The report must serve two different audiences:
Management needs to understand risk and priorities.
Technical teams need enough detail to reproduce and remediate the issue.
5.10. Remediate and Retest
Retesting confirms that the implemented fix:
Addresses the root cause.
Does not merely hide the symptom.
Does not introduce a new weakness.
Works effectively in the actual environment.
6. What should a PENTEST report include?
A high-quality report should not be judged by its page count or by the number of vulnerabilities listed.
It should include:
An executive summary.
Testing objectives.
Scope and limitations.
Testing dates.
Methodology.
Validated findings.
Exploitation conditions.
Appropriate evidence.
Affected systems and data.
Attack chains, where relevant.
Risk ratings and assessment criteria.
Remediation guidance.
Retest status.
The report should also distinguish between:
Vulnerabilities successfully exploited.
Weaknesses that appear exploitable but could not be tested further.
Findings that could not be fully validated.
Limitations caused by scope or time constraints.
After receiving the report, organisations can review IPSIP’s guide on how to read a PENTEST report and remediate vulnerabilities.
How Should a Successful PENTEST Be Evaluated?
A PENTEST should not be judged by how many vulnerabilities the provider reports.
More useful success criteria include:
The agreed scope was tested.
Findings can be reproduced.
Evidence is clear without collecting excessive sensitive data.
Risks are linked to business assets and impact.
Technical teams understand the remediation steps.
Critical findings are prioritised.
Retesting confirms that fixes are effective.
Lessons are incorporated into development and operational processes.
Businesses can also review IPSIP’s guidance on remediating findings from a penetration testing report.
7. Does Vietnamese Law require businesses to conduct PENTEST?
It would be inaccurate to state that every business in Vietnam is legally required to perform PENTEST on the same schedule.
The specific obligations depend on factors such as:
The type of organisation.
The systems being operated.
The classified security level of the information system.
The industry.
The type of data being processed.
Regulatory requirements.
Customer contracts.
Standards adopted by the organisation.
However, Vietnam’s legal and regulatory environment in 2026 makes technical validation of security controls increasingly relevant.
The Law on Personal Data Protection No. 91/2025/QH15 took effect on 1 January 2026. The Government also issued Decree No. 356/2025/ND-CP, which provides detailed regulations and implementation measures for the Law.
The Cybersecurity Law No. 116/2025/QH15 was enacted on 10 December 2025 and took effect on 1 July 2026.
For information systems subject to security-level classification requirements, Circular No. 12/2022/TT-BTTTT provides detailed guidance for implementing parts of Decree No. 85/2016/ND-CP. Directive No. 09/CT-TTg, dated 23 February 2024, also called for stronger compliance with information-system security requirements by classification level.
These regulations should not be simplified into the statement that every company must conduct PENTEST.
Instead, PENTEST can support organisations by:
Validating selected security controls.
Identifying weaknesses that could affect protected data.
Creating evidence for risk-management activities.
Supporting assessments before systems are connected or launched.
Preparing for customer, group, regulator, or audit requirements.
Businesses should evaluate their obligations with legal counsel, industry requirements, contractual commitments, and the specific characteristics of their information systems.
8. What should foreign-invested enterprises consider when conducting PENTEST in Vietnam?
Foreign-invested enterprises often operate more complex environments because systems, data, ownership, and security responsibilities may be distributed across several countries.
Before testing begins, the organisation should clarify the following areas.
8.1. Approval Authority
The local IT team in Vietnam may not be the final owner of the system.
Approval may be required from:
Global headquarters.
Application owners.
Regional security teams.
Global Cloud teams.
Service providers.
Customers that own the affected data.
8.2. Location of Assets and Data
An application may operate in Vietnam while its data is hosted in another region. Conversely, an application managed overseas may process employee or customer data from Vietnam.
The scope should clearly define:
Where the system is located.
What data may appear in testing evidence.
Who may access the report.
Where the report and test data will be stored.
How long evidence will be retained.
How data will be deleted after the project.
8.3. Reporting Language
A foreign-invested enterprise may require:
A technical report in English.
An executive summary in Vietnamese.
A shared remediation tracker.
Risk classifications aligned with the group’s security framework.
Presentations for both local and regional teams.
8.4. Production Systems and Time Zones
Testing may affect users across several countries. The Rules of Engagement should specify time zones, maintenance windows, and escalation procedures.
8.5. Cloud Providers and Third Parties
Some Cloud and service providers have specific security-testing policies. The organisation should review contractual responsibilities and provider requirements before beginning the engagement.
9. When should a business conduct PENTEST?
Common triggers include:
Before launching a critical application.
Before opening a system to customers or partners.
After major architectural changes.
After introducing a new API.
After migrating to the Cloud.
After significant changes to Active Directory or identity systems.
After a merger or network integration.
After a cybersecurity incident.
Before a customer or partner security assessment.
When required by contracts or standards.
After remediating critical vulnerabilities.
When newly disclosed vulnerabilities affect the technologies in use.
CISA maintains the Known Exploited Vulnerabilities Catalog to help organisations prioritise vulnerabilities that have evidence of exploitation in the real world.
The existence of a vulnerability in this catalogue does not automatically mean every affected organisation needs a full PENTEST. However, it reinforces the need to evaluate whether the affected product is present, reachable, exploitable, and properly mitigated.
For businesses that release software frequently, one annual PENTEST may not be sufficient. PENTEST should be linked to high-risk changes, while automated security testing and vulnerability scanning are performed more regularly.
More detail is available in IPSIP’s article on how often businesses should conduct penetration testing.
10. What factors affect PENTEST costs?
The cost of a PENTEST commonly depends on:
The type of system.
The number of assets.
The number of user roles.
The number of APIs or business workflows.
Whether the assessment is black-box, grey-box, or white-box.
Architectural complexity.
Whether testing is performed in production or staging.
The testing window.
Reporting requirements.
The number of retest rounds.
After-hours work.
Language and international coordination requirements.
Two applications with the same number of URLs may require very different levels of effort.
A SaaS platform with multiple tenants, user roles, integrations, and payment flows will usually require deeper testing than a corporate information website.
For this reason, a quotation based only on the number of IP addresses or URLs may not accurately reflect the security risk.
Businesses planning their budget can review IPSIP’s article on the cost of recurring PENTEST.
11. How should a business select a PENTEST provider in Vietnam?
A provider should be evaluated during the scoping stage, not only on the basis of certificates or a sample report.
Important questions include:
Does the provider ask about business objectives?
Does the team have experience with the relevant asset type?
Are included and excluded systems clearly documented?
Are the Rules of Engagement complete?
How will testing data be protected?
Who will have access to evidence?
Does the report distinguish automated alerts from validated findings?
Are the recommendations suitable for the actual architecture?
Is a technical presentation included?
Is retesting included?
Can the provider deliver bilingual reports?
Can the team coordinate with overseas IT and security teams?
Is there a clear process for handling conflicts or incidents during testing?
A provider should not be selected based on a promise to “find the highest number of vulnerabilities”.
A report containing hundreds of automated alerts without validation can consume more internal resources than a shorter report focused on meaningful attack paths and business risks.
12. Conclusion
PENTEST helps a business move from the question:
“Does the system have vulnerabilities?”
to the more useful question:
“Which weaknesses can be exploited, what assets could be affected, and what should we remediate first?”
An effective system penetration testing programme should:
Start with business risk.
Define a clear scope.
Include written authorisation and Rules of Engagement.
Combine automated tools with manual testing.
Protect data throughout the engagement.
Serve both management and technical audiences.
Include a remediation plan.
Include retesting after fixes are implemented.
For Vietnamese businesses and foreign-invested enterprises, the PENTEST scope should also align with approval structures, data locations, contractual requirements, group policies, and the legal framework applicable in Vietnam.
IPSIP provides PENTEST and system penetration testing services for web applications, APIs, mobile applications, Cloud environments, and enterprise infrastructure. The scope is built around actual assets, risk scenarios, and business objectives rather than applying the same checklist to every system.
-----------------------
Frequently Asked Questions
Can PENTEST Disrupt a Production System?
PENTEST can create operational risk when performed in production. The risk should be controlled through the agreed scope, maintenance windows, stop conditions, monitoring, and emergency communication channels. Techniques that may cause disruption should not be used without explicit approval.
Does PENTEST Replace Vulnerability Scanning?
No. Vulnerability scanning is suitable for frequent, broad monitoring. PENTEST focuses on exploitability, business logic flaws, and attack chains. The two activities complement each other.
How Often Should a Business Conduct PENTEST?
The frequency depends on the importance of the asset, the rate of change, Internet exposure, customer requirements, contractual obligations, and previous findings. In addition to scheduled testing, businesses should consider PENTEST after major security-relevant changes.
Is Retesting Necessary After Remediation?
Yes, particularly for critical findings. Retesting confirms that the fix addresses the root cause and has not introduced another weakness.
----------------
References
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/pubs/sp/800/115/final
NIST Glossary — Penetration Testing: https://csrc.nist.gov/glossary/term/penetration_testing
OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
OWASP Web Security Testing Guide — Stable: https://owasp.org/www-project-web-security-testing-guide/stable/
Luật số 91/2025/QH15 — Luật Bảo vệ dữ liệu cá nhân: https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160
Nghị định số 356/2025/NĐ-CP quy định chi tiết Luật Bảo vệ dữ liệu cá nhân: https://vanban.chinhphu.vn/?docid=216387&pageid=27160
Luật số 116/2025/QH15 — Luật An ninh mạng: https://vanban.chinhphu.vn/?classid=1&docid=216499&pageid=27160
Thông tư số 12/2022/TT-BTTTT về bảo đảm an toàn hệ thống thông tin theo cấp độ: https://vanban.chinhphu.vn/?docid=206402&pageid=27160
Chỉ thị số 09/CT-TTg về tăng cường bảo đảm an toàn hệ thống thông tin theo cấp độ: https://vanban.chinhphu.vn/?docid=209779&pageid=27160
CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Comments