Penetration Test

A company wants to know whether its customer portal can expose records to the wrong account, and a penetration test lets approved testers investigate that question within agreed boundaries. The result is evidence about a defined scope and time, not a guarantee that everything is secure.

NIST treats penetration testing as part of broader security assessment, and OWASP's web testing guidance distinguishes tests and stresses actionable reporting for developers and business stakeholders. Write authorization first, because the owner of each target system must permit the work and a vendor's general contract is not a substitute for clear scope.

Define targets by listing domains, applications, APIs, cloud accounts and networks in scope, and exclude systems owned by customers or suppliers unless they explicitly authorize testing. Set dates and hours, since intensive testing can affect live services, and agree on maintenance windows, emergency contacts and stop conditions.

Agree on methods, deciding whether phishing, physical access, denial-of-service tests and social engineering are included, because they should not be assumed. Protect data, since testers may encounter real customer records or credentials, by setting collection, storage, access and deletion rules.

Choose the testing view: an external test imitates an outsider, an internal test starts from network access, and authenticated application testing can reveal flaws hidden from an anonymous view. Provide needed context, because accounts with different user roles can help test authorization and a clear architecture diagram can save time without making the test meaningless.

Identify assets, since public pages, old subdomains and forgotten APIs may create unexpected routes and inventory work is part of proper scoping. Look for weaknesses such as misconfiguration, outdated components and broken access controls, because a good test goes beyond running automated tools, and demonstrate impact safely by obtaining enough proof to validate a finding without extracting unnecessary private data or harming service.

Escalate urgent findings, since a critical live flaw should reach the agreed contact promptly and need not wait for the final report. Receive a readable report in which each finding describes the affected asset, evidence, business impact and recommended repair, because technical proof and executive summary serve different audiences, and prioritise by context, since a flaw on a public payment portal may carry more risk than the same pattern in a restricted test tool and severity labels require explanation.

Assign fixes, as development, infrastructure and access teams may own different findings and a report with no owner becomes an unused document, retest repairs because closing a ticket is not the same as confirming the weakness is gone, and track residual risk by recording interim controls, owner and review date for findings that cannot be fixed immediately. Understand limitations: a test samples systems, techniques and time, and new releases and newly discovered flaws can change the picture after it ends.

Do not confuse it with compliance, because a required annual test can satisfy a reporting obligation but passing it is not an ongoing security program, and coordinate with operations so monitoring teams can distinguish authorized traffic from an attack while preserving useful detection practice. Check supplier access so you know who can authorize tests of third-party hosted applications, budget for remediation because fixes and verification need engineering time, repeat after major redesigns, new payment flows or cloud migrations, and remember that for owners the useful outcome is a prioritised, validated repair plan, not a thick report or a count of findings.