01
Test real user roles
Validate what anonymous, standard, privileged and cross-tenant users can actually do.
Web application penetration testing
Test the application as an attacker, a normal user and a user trying to cross the trust boundary.
Damocles Web Application Penetration Testing assesses authentication, authorisation, session handling, business logic, input processing, file handling and sensitive-data exposure across approved public and authenticated application functions.
Public and authenticated testingRole and tenancy abuseBusiness-logic testingDeveloper-ready evidence
Why customers buy this test
Test the controls protecting application users, data and workflows.
Web applications can be secure at the infrastructure layer and still expose serious flaws in authorisation, tenancy, workflow, file handling or business logic. The assessment tests how the application behaves across unauthenticated and authenticated states and whether users can access functions or data outside their intended role.
Testing is suited to customer portals, administrative interfaces, SaaS applications, line-of-business systems and internet-facing applications where the consequence of account or data abuse is material.
02
Test business logic
Look for workflow, state, approval, limit and sequence abuse that automated scanners do not understand.
03
Give developers usable evidence
Provide reproducible requests, affected functions, conditions and remediation guidance.
What we test
Application functions, identities, roles and data flows in the agreed web application.
Representative test accounts and a stable test environment materially improve coverage for authenticated and role-based testing.
AU
Authentication
Login, MFA integration, recovery, account lifecycle and authentication bypass conditions.
AZ
Authorisation
Role checks, object ownership, administrative functions, tenant separation and server-side enforcement.
SS
Sessions and tokens
Session creation, expiry, fixation, logout, token handling and unsafe client/server trust.
BL
Business logic
Workflow sequence, approvals, duplicate actions, limits, state changes and unintended feature abuse.
IH
Input and file handling
Injection paths, encoding, uploads, downloads, file processing and unsafe server-side handling.
DA
Sensitive data
Exposure of customer, credential, financial, operational or other protected information through application behaviour.
Technical assurance
Test the controls that protect application users, data and workflows.
Test the application from public, authenticated, cross-role and integration perspectives to identify weaknesses that could expose accounts, data, privileged functions or business workflows.
Authentication and recovery
Login, MFA, reset and recovery weaknesses.
Authorisation and tenant isolation
Role, object, function and cross-tenant access controls.
Sessions and tokens
Cookie, session and token lifecycle, replay and revocation.
Input and output handling
Injection, unsafe parsing and browser output risks.
Business logic
Workflow bypass, replay, limits and misuse of legitimate functionality.
Browser security
Client-side trust, storage, messaging and CORS.
Files and integrations
Upload, download, APIs, webhooks and integration boundaries.
Logging and auditability
Whether relevant security events can be traced when operational evidence is available.
What we actually test
Jump to full coverage matrix ↓Representative technical coverage with the evidence produced.
These are governed procedures from the service assurance profile—not generic marketing categories. The complete matrix below records applicability, access requirements and limitations for every coverage area.
Discovery and entry points
Damocles enumerates approved application hosts, routes, parameters, virtual hosts and public entry points, reconciles them with the supplied inventory and records unexpected or missing exposure.
Architecture and trust boundaries
Damocles reviews diagrams and discovered entry points, identifies browser, application, API, identity, storage and third-party boundaries, then tests representative runtime crossings to confirm where trust is enforced.
Configuration
Damocles reviews deployment mode, security headers, CORS, error exposure, debug behaviour, administrative interfaces, default content and transport settings, then validates externally observable behaviour.
Identity lifecycle
Damocles tests registration, invitation, activation, role assignment, suspension, deactivation, deletion and reactivation paths, including orphaned identities and administrative lifecycle actions where included.
Authentication, MFA and recovery
Damocles tests login controls, account enumeration, MFA enrolment and enforcement, recovery paths, reset tokens, alternate authentication routes, session establishment and approved lockout or throttling thresholds.
Role, function, object and tenant authorisation
Damocles attempts permitted and denied functions and varies representative object identifiers across standard, privileged and cross-role or cross-tenant identities to verify server-side role, function, object and tenant enforcement.
Showing 6 representative areas. The full governed matrix contains 16 coverage areas.
Standards and assurance coverage
See how this engagement is structured, classified and mapped before opening the full evidence matrix.
References are shown according to the role they play in the engagement. Methodologies guide testing, taxonomies classify findings, severity methods support consistent scoring, and control mappings connect scoped evidence to broader assurance work.
How testing is structured
Approved methodology, verification and testing guidance used to select and structure relevant procedures within the authorised scope.
How weaknesses and severity are classified
Approved risk, weakness and severity references provide a consistent language for confirmed findings without replacing customer-specific business impact.
What maps into compliance and assurance work
12governed evidence mappings across 7 approved frameworks and 13 referenced controls.
4 directly assessed4 supporting evidence4 contextual
Information Security Manual June 2026Directly assessed
ISM-1552ISM-1241ISM-1424
Observed HTTPS enforcement, output encoding and security response-header behaviour where those controls are present.
Information Security Manual June 2026Supporting evidence
ISM-0971ISM-1850ISM-1851
Application behaviour relevant to agreed ASVS requirements and OWASP web or API risk categories.
Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Directly assessed
AC-3
Tests server-side enforcement of role, function, object and tenant authorisation using representative identities and objects included in scope.
+ 9 additional governed mappings in the full control matrix.
Jump to full control mapping ↓What the customer can use after the engagement
A prioritised technical report with reproducible evidence, affected roles or functions, remediation guidance and retest results.
- Authorised scope and rules of engagement
- Coverage matrix
- Retest and residual-risk record
- + 3 additional controlled outputs
What this means: technical evidence may support risk, compliance and audit activity where the mapping is applicable. It does not by itself certify the organisation, establish complete compliance or assess controls outside the authorised scope.
Manual validation backed by controlled evidence.
Damocles combines unauthenticated, role-based and architecture-assisted testing, retaining HTTP evidence for each observed behaviour. Document or configuration review is identified separately from runtime validation, and testing stops before availability, destructive data or uncontrolled account impact.
Evidence is mapped to the part of a control we can actually assess.
Directly assessed means the engagement tests the relevant behaviour. Supporting evidence means the result can contribute to a broader control assessment. Contextual references explain relevance without claiming that the control was tested.
All relevant frameworks
Web Security Testing Guide 4.2Application Security Verification Standard 5.0.0OWASP Top 10 2025OWASP API Security Top 10 2023Common Weakness Enumeration 4.20Common Vulnerability Scoring System 4.0Guidelines for Software Development June 2026Information Security Manual June 2026Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Prudential Standard CPS 234 Information Security effective 1 July 2019Prudential Practice Guide CPG 234 Information Security published June 2019ISO/IEC 27001 2022 with Amendment 1:2024ISO/IEC 27002 2022Payment Card Industry Data Security Standard 4.0.1
Testing perspectives6 authorised viewpoints and access models
Unauthenticated application user
Exercises public routes, registration, login, recovery and pre-authentication browser behaviour without an account.
Standard authenticated user
Uses a dedicated ordinary account to test sessions, workflows, data handling and server-side enforcement.
Cross-role or cross-tenant identity
Repeats equivalent object and function requests between controlled roles or tenants to test isolation.
Privileged application user
Exercises administrative functions and privilege transitions with a controlled privileged account.
Integration or API client
Calls approved APIs, webhooks and callbacks using scoped client credentials and controlled payloads.
Architecture-assisted reviewer
Correlates runtime requests with diagrams, deployment settings, trust boundaries, logging and cryptographic design evidence.
Exact test coverage and evidence16 governed coverage areas
| Coverage area | What Damocles tests | Perspective and access | Evidence produced | References and limits |
|---|---|---|---|---|
| Discovery and entry points | Damocles enumerates approved application hosts, routes, parameters, virtual hosts and public entry points, reconciles them with the supplied inventory and records unexpected or missing exposure. | Unauthenticated application user Approved hostnames, base URLs, deployment inventory, public documentation and test window. | Discovered host, route, parameter and response evidence is mapped to the expected application entry-point inventory. | Web Security Testing Guide 4.2 · WSTG-v42-INFO-02, WSTG-v42-INFO Applicability: Applies to public and supplied application entry points included in the authorised scope. Limit: Discovery is bounded to approved hosts and does not establish hidden functionality that is unreachable from the tested position. |
| Architecture and trust boundaries | Damocles reviews diagrams and discovered entry points, identifies browser, application, API, identity, storage and third-party boundaries, then tests representative runtime crossings to confirm where trust is enforced. | Architecture-assisted reviewer Current architecture and data-flow diagrams, component and integration inventory, approved URLs, representative accounts and technical owners. | Annotated boundary observations linked to the diagram, entry point and representative request or response used to validate the crossing. | Web Security Testing Guide 4.2 Applicability: Included when architecture evidence is supplied or multiple components and trust domains are in scope. Limit: Diagrams may not match every deployment; runtime testing covers representative crossings and does not authorise testing the third party itself. |
| Configuration | Damocles reviews deployment mode, security headers, CORS, error exposure, debug behaviour, administrative interfaces, default content and transport settings, then validates externally observable behaviour. | Architecture-assisted reviewer Approved application URLs, deployment and security configuration, expected headers and CORS policy, and representative public and authenticated routes. | Configuration excerpts and HTTP request-and-response pairs showing the observed header, CORS, error, debug, default-content or administrative behaviour. | Web Security Testing Guide 4.2 · WSTG-v42-CONF Applicability: Included when the relevant setting is observable or configuration evidence is supplied. Limit: A snapshot cannot prove consistent settings across excluded nodes or future releases; no production configuration is changed during review. |
| Identity lifecycle | Damocles tests registration, invitation, activation, role assignment, suspension, deactivation, deletion and reactivation paths, including orphaned identities and administrative lifecycle actions where included. | Unauthenticated application user Assessment requires approved URLs, controlled accounts, representative data and relevant architecture or configuration evidence, selected specifically for identity lifecycle. | Evidence records the HTTP request, response, browser state, rendered output or cited configuration evidence relevant to identity lifecycle. | Web Security Testing Guide 4.2 · WSTG-v42-IDNT Applicability: Applies to Identity lifecycle when the feature and representative identity are present in the authorised application. Limit: The conclusion is limited to the sampled identity lifecycle; results cover supplied roles, data and workflows; destructive data and availability impact are excluded. |
| Authentication, MFA and recovery | Damocles tests login controls, account enumeration, MFA enrolment and enforcement, recovery paths, reset tokens, alternate authentication routes, session establishment and approved lockout or throttling thresholds. | Unauthenticated application user, Standard authenticated user Unauthenticated login and recovery endpoints, standard test accounts, MFA factors, recovery channels and privileged authentication only where administration is in scope. | HTTP exchanges and state observations record enumeration differences, MFA decisions, recovery-token handling, established sessions and bounded throttling results. | Web Security Testing Guide 4.2 · WSTG-v42-ATHN Applicability: Applies to each customer-approved authentication, MFA and recovery path exposed by the application. Limit: Credential attempts remain within approved thresholds; Damocles does not lock real users, intercept third-party recovery messages or exhaust availability. |
| Role, function, object and tenant authorisation | Damocles attempts permitted and denied functions and varies representative object identifiers across standard, privileged and cross-role or cross-tenant identities to verify server-side role, function, object and tenant enforcement. | Standard authenticated user, Cross-role or cross-tenant identity, Privileged application user At least two representative identities in different roles or tenants, privileged access where included, representative objects and the expected access matrix. | HTTP request-and-response pairs identify each identity, object or function, expected decision and observed authorisation result. | Web Security Testing Guide 4.2 · WSTG-v42-ATHZ Applicability: Applies to server-side functions, records and tenant boundaries reachable by the supplied identities. Limit: Results cover only the supplied roles, tenants and objects; destructive changes and access to real customer data are prohibited. |
| Sessions, cookies and tokens | Damocles examines cookies, browser sessions and tokens across issuance, client storage, renewal, expiry, logout, revocation, fixation, replay and privilege changes. | Standard authenticated user, Privileged application user Standard authenticated accounts, privileged accounts where relevant, test browsers, issued tokens and documented session settings. | Cookie attributes, token claims and HTTP exchanges show lifecycle transitions, replay outcomes, revocation and privilege-change behaviour. | Web Security Testing Guide 4.2 · WSTG-v42-SESS Applicability: Applies to session or token mechanisms used by the supplied application identities. Limit: Testing does not assert lifecycle behaviour for excluded clients or identities and stops before disruption of shared identity services. |
| Input validation and injection | Damocles identifies interpreters and data contexts, submits safe representative payloads through reachable inputs, observes server-side handling and stops before destructive queries, commands or downstream effects. | Unauthenticated application user Approved routes and parameters, representative accounts and records, technology context where available, and prohibited payload or data boundaries. | HTTP requests and responses showing the input, encoding, server behaviour and the minimum non-destructive proof for a confirmed injection condition. | Web Security Testing Guide 4.2 · WSTG-v42-INPV Applicability: Applied to public and authenticated inputs reachable by the supplied perspectives. Limit: No destructive query, command execution, bulk extraction or unsafe out-of-band interaction is attempted without separate authority. |
| Output encoding | Damocles submits safe marker values through an identity able to create the affected data and observes rendering in HTML, attribute, URL, script and other relevant output contexts. | Standard authenticated user The submitting and viewing identities, representative writable fields, affected pages and approved marker payloads. | The originating request, returned response, DOM or rendered result and exact output context are retained. | Web Security Testing Guide 4.2 Applicability: Applies to user-controlled values that the application returns or renders in a browser or downstream document. Limit: Active exploitation is limited to harmless proof; Damocles does not execute payloads that access real data or affect other users. |
| Error handling | Damocles sends malformed requests and triggers bounded exceptional conditions from unauthenticated and representative authenticated viewpoints, comparing response content, status, timing and recovery behaviour. | Unauthenticated application user, Standard authenticated user Approved endpoints, unauthenticated access, standard test accounts and known safe malformed values or exceptional conditions. | Request-and-response pairs capture status, error details, identifiers, stack information and subsequent application availability. | Web Security Testing Guide 4.2 · WSTG-v42-ERRH Applicability: Applies to reachable request handlers and workflows where safe exceptional conditions can be produced. Limit: No deliberate availability impact, resource exhaustion or destructive fault injection is performed. |
| Transport and cryptography | Damocles tests externally observable TLS versions, certificates, protocol negotiation and transport enforcement, and reviews application cryptographic use only when architecture or configuration evidence is supplied. | Unauthenticated application user, Architecture-assisted reviewer Approved hostnames and endpoints, an unauthenticated client path, and cryptographic design or configuration evidence when review is included. | Certificate and protocol observations, redirect or enforcement responses, and cited configuration excerpts support each conclusion. | Web Security Testing Guide 4.2 · WSTG-v42-CRYP Applicability: Applies to in-scope application transport and to cryptographic implementation expressly included with supporting evidence. Limit: External observation cannot establish internal key custody or implementation; intrusive downgrade and denial-of-service testing are excluded. |
| Business logic, workflow, replay and limits | Damocles follows required sequences and state transitions, safely repeats or replays operations, tests quantity, value and approval limits, and checks whether concurrency or legitimate features can bypass prerequisites across relevant roles or tenants. | Standard authenticated user Assessment requires approved URLs, controlled accounts, representative data and relevant architecture or configuration evidence, selected specifically for business logic, workflow, replay and limits. | Evidence records the HTTP request, response, browser state, rendered output or cited configuration evidence relevant to business logic, workflow, replay and limits. | Web Security Testing Guide 4.2 · WSTG-v42-BUSL Applicability: Applies to Business logic, workflow, replay and limits when the feature and representative identity are present in the authorised application. Limit: The conclusion is limited to the sampled business logic, workflow, replay and limits; results cover supplied roles, data and workflows; destructive data and availability impact are excluded. |
| Browser-side trust, storage, messaging and CORS | Damocles inspects browser storage and sensitive client-side state, exercises cross-window and cross-origin messaging, validates CORS trust, and tests whether client-enforced restrictions or browser-controlled values can be bypassed. | Architecture-assisted reviewer Assessment requires approved URLs, controlled accounts, representative data and relevant architecture or configuration evidence, selected specifically for browser-side trust, storage, messaging and CORS. | Evidence records the HTTP request, response, browser state, rendered output or cited configuration evidence relevant to browser-side trust, storage, messaging and CORS. | Web Security Testing Guide 4.2 · WSTG-v42-CLNT Applicability: Applies to Browser-side trust, storage, messaging and CORS when the feature and representative identity are present in the authorised application. Limit: The conclusion is limited to the sampled browser-side trust, storage, messaging and CORS; results cover supplied roles, data and workflows; destructive data and availability impact are excluded. |
| File handling | Damocles tests file type and content validation, filename and path handling, storage access, upload and download authorisation, preview or transformation services, active content, and size or processing limits within safe thresholds. | Unauthenticated application user Assessment requires approved URLs, controlled accounts, representative data and relevant architecture or configuration evidence, selected specifically for file handling. | Evidence records the HTTP request, response, browser state, rendered output or cited configuration evidence relevant to file handling. | Web Security Testing Guide 4.2 Applicability: Applies to File handling when the feature and representative identity are present in the authorised application. Limit: The conclusion is limited to the sampled file handling; results cover supplied roles, data and workflows; destructive data and availability impact are excluded. |
| APIs, webhooks and integrations | Damocles uses the supplied integration or API client to test API authentication, authorisation and scopes, callback destination validation, webhook authenticity and replay, secret or signature handling, retry behaviour and third-party trust boundaries. | Integration or API client, Standard authenticated user API or integration credentials, schemas, representative objects for each role or tenant, webhook signing material and a controlled callback endpoint. | API request-and-response pairs, webhook payload and signature results, callback observations and affected identity, tenant or object details. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Included only for APIs, webhooks and integrations explicitly named in scope. Limit: Testing does not authorise assessment of the third-party provider; callbacks, retries and state changes use controlled records and stop at agreed limits. |
| Logging, alerting and auditability | Damocles generates representative application events and, when log access is supplied, asks the operational reviewer to confirm the audit record, alert and handling outcome; absence of log access is recorded rather than inferred. | Standard authenticated user, Architecture-assisted reviewer A test account and records, agreed event scenarios, read-only application or central log access, expected source inventory and an operational reviewer. | The generating request, event timestamp and identifier, received log record, alert or workflow status and any missing-field or delivery gap. | Web Security Testing Guide 4.2 Applicability: End-to-end confirmation is included only when log or workflow access is supplied; otherwise the row records that receipt was unable to be validated. Limit: A small event sample cannot prove continuous logging or detection; no conclusion is drawn about downstream handling when operational evidence is unavailable. |
Framework and control mappings12 governed evidence mappings
| Framework and controls | Mapping type | What Damocles assesses | Evidence produced | Applicability and limits |
|---|---|---|---|---|
| Information Security Manual June 2026 ISM-1552ISM-1241ISM-1424 | Directly assessed | Observed HTTPS enforcement, output encoding and security response-header behaviour where those controls are present. | Requests, responses and browser-observed behaviour linked to the affected route. | Applies: Only the relevant application routes and behaviours in scope. Limit: Does not prove continuous enforcement or development-lifecycle governance. |
| Information Security Manual June 2026 ISM-0971ISM-1850ISM-1851 | Supporting evidence | Application behaviour relevant to agreed ASVS requirements and OWASP web or API risk categories. | Coverage and findings that may inform a broader secure-development assessment. | Applies: API references apply only when APIs are expressly included. Limit: A point-in-time test cannot prove that the development lifecycle used ASVS or mitigated every taxonomy category. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 AC-3 | Directly assessed | Tests server-side enforcement of role, function, object and tenant authorisation using representative identities and objects included in scope. | Reproducible request and response pairs, role and object context, expected-versus-observed authorisation outcomes, and finding or retest evidence where applicable. | Applies: Applies where multiple roles, tenants, ownership boundaries or restricted functions are included with representative test identities and data. Limit: Does not assess the customer's complete access-control policy, identity governance, every role or object, or enforcement outside the sampled application paths. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 SC-8 | Directly assessed | Tests whether in-scope web endpoints protect application traffic in transit through HTTPS enforcement and observed protocol and certificate behaviour. | Connection observations, redirect and enforcement results, certificate or protocol evidence, and affected endpoint records. | Applies: Applies to in-scope application endpoints and transport paths that can be exercised safely during the engagement. Limit: Point-in-time application testing does not assess every system-to-system path, cryptographic key-management process or continuous transport configuration. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 SI-10 | Directly assessed | Tests how in-scope application inputs are validated and processed across representative parameters, request bodies, files and interpreter boundaries. | Representative payloads, requests and responses, observed validation or interpreter behaviour, affected functions and reproducible finding evidence. | Applies: Applies to reachable input paths, parsers, file-processing functions and server-side interpreter boundaries expressly included in scope. Limit: Sampling cannot establish that every input, parser, code path or downstream component performs equivalent validation. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 AU-2AU-3 | Supporting evidence | Where application or security logs are supplied, generates representative authentication, authorisation and error events and checks whether the tested action can be traced in the resulting event records. | Timestamped test actions correlated to supplied log entries, including available event type, identity or source, outcome and security-relevant context. | Applies: Applies only when relevant application or security logging is in scope and Damocles is given sufficient access to correlate generated events with recorded output. Limit: Does not establish the organisation's event-selection policy, complete audit-record content, retention, centralisation, review process or continuous monitoring coverage. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 CA-8 | Supporting evidence | Performs an authorised point-in-time penetration test across the agreed application attack perspectives and records scope, procedures, findings, evidence and retest outcomes. | Rules of engagement, coverage matrix, reproducible technical findings, attack-path evidence, remediation guidance and retest records where included. | Applies: Relevant where the customer uses scoped penetration testing as one input to a broader security assessment or penetration-testing program. Limit: Does not establish organisation-defined testing frequency, enterprise coverage, assessor-governance requirements or the completeness of the customer's broader assessment program. |
| Prudential Standard CPS 234 Information Security effective 1 July 2019 CPS 234 paragraph 27 | Supporting evidence | Provides scoped penetration-testing evidence for the effectiveness of application security controls exposed to internet or other untrusted environments, including authorisation, authentication, input handling, transport, workflow and logging behaviour where included. | Governed coverage records, reproducible findings, affected scope, remediation evidence and retest results that can be incorporated into the customer's control-testing records. | Applies: Relevant to an APRA-regulated entity where this engagement is one activity within the systematic testing program required by CPS 234 paragraph 27. Limit: Does not by itself establish the systematic testing program, testing frequency, full control population, specialist independence, Board or senior-management reporting, annual program review or compliance with other CPS 234 requirements. |
| Prudential Practice Guide CPG 234 Information Security published June 2019 Framework-level context | Contextual | Produces scoped application penetration-testing evidence consistent with CPG 234 guidance that control testing use techniques suited to the control, including penetration testing for internet exposure, unauthorised access and secure-software assurance. | Scope and rules of engagement, coverage records, technical findings, remediation guidance and retest evidence where included. | Applies: Used as prudential guidance context when an APRA-regulated customer is determining how this engagement contributes to its broader testing program. Limit: CPG 234 is guidance rather than a standalone certification target; this contextual mapping does not claim assessment of the complete guidance or the customer's testing program. |
| ISO/IEC 27001 2022 with Amendment 1:2024 Framework-level context | Contextual | Produces scoped technical evidence that may be used by the customer within ISO/IEC 27001 risk treatment, assurance and audit activities where the tested application and findings are relevant. | Governed scope, coverage records, findings, remediation evidence and retest results where included. | Applies: Relevant only where the customer has determined that the assessed application and technical evidence form part of its ISMS scope or assurance activity. Limit: Licensed control identifiers and text are intentionally withheld. The engagement does not establish ISO/IEC 27001 certification, whole-ISMS conformity or control effectiveness outside the authorised scope. |
| ISO/IEC 27002 2022 Framework-level context | Contextual | Provides application-security test evidence that can inform customer-selected ISO/IEC 27002 control implementation and assurance where the tested behaviour is relevant. | Technical findings, evidence, affected functions, remediation guidance and retest results where included. | Applies: Relevant only after the customer establishes which ISO/IEC 27002 guidance is applicable to the assessed application and its risk treatment. Limit: Licensed control identifiers and text are intentionally withheld. This mapping is contextual and does not claim complete ISO/IEC 27002 assessment or compliance. |
| Payment Card Industry Data Security Standard 4.0.1 Framework-level context | Contextual | Provides scoped web-application penetration-testing evidence that may support PCI DSS assurance activity when the assessed application is confirmed by the customer to be in, connected to or security-relevant to the applicable cardholder-data environment. | Scope records, tested application paths, reproducible findings, remediation guidance and retest evidence where included. | Applies: Relevant only where the customer or its qualified assessor confirms that the application and engagement fall within the applicable PCI DSS scope. Limit: Licensed requirement identifiers and text are intentionally withheld. Damocles does not represent this engagement as a PCI DSS assessment, attestation or certification. |
Assurance boundary: Damocles maps assessed coverage and findings to agreed security frameworks and control objectives. This provides traceable technical evidence that may support risk, assurance and audit activities. A penetration test does not by itself certify an organisation, establish complete compliance with a framework or confirm the effectiveness of controls outside the authorised scope.
Report and evidence outputs6 controlled output types
Authorised scope and rules of engagement
Records authorised scope and rules of engagement produced from the authorised Web application penetration testing work.
Coverage matrix
Records coverage matrix produced from the authorised Web application penetration testing work.
Retest and residual-risk record
Records retest and residual-risk record produced from the authorised Web application penetration testing work.
HTTP request-and-response evidence
Records http request-and-response evidence produced from the authorised Web application penetration testing work.
Role and tenant coverage matrix
Records role and tenant coverage matrix produced from the authorised Web application penetration testing work.
Workflow and authorisation evidence
Records workflow and authorisation evidence produced from the authorised Web application penetration testing work.
What you receive
A prioritised technical report with reproducible evidence, affected roles or functions, remediation guidance and retest results.
Attack paths we look for
Application attack paths that can cross roles, tenants and sensitive workflows.
The exact tests are driven by the application design, roles and approved scope.
ID
Broken object authorisation
Access to another user or tenant object through identifier manipulation or missing server-side checks.
PF
Privilege-function abuse
Use of administrative or higher-privilege functions from a lower-privilege role.
BL
Workflow bypass
Skipping approval, sequence, payment, limit or validation steps to create an unauthorised outcome.
IN
Injection and unsafe input
Input that changes interpreter, query, template or server-side behaviour.
SS
Session abuse
Weak session lifecycle, token handling or account transitions that allow access beyond intended identity state.
SD
Sensitive-data exposure
Application responses, errors, files or functions that disclose protected information.
Engagement options
Choose the access depth and release context required.
The scope identifies roles, accounts, application areas, excluded functions, data sensitivity and whether a test environment or production system is used.
BX
Public attack-surface test
Assess the application from an unauthenticated attacker perspective.
AU
Authenticated user testing
Use approved accounts to test post-login functions, role boundaries and data access.
MT
Role and tenant testing
Compare standard, privileged and tenant-separated roles to validate enforcement.
RL
Pre-release application test
Assess a defined release before production or customer rollout.
RT
Application retest
Retest agreed findings after remediation and record the outcome.
What you receive
Application findings with enough detail for developers to reproduce and fix the issue.
Evidence is mapped to the affected function, role, request and expected security boundary.
ES
Executive application risk
Material compromise, data exposure and business-workflow risks explained without raw scanner noise.
RQ
Reproducible requests
Request, response and role context required to reproduce material findings.
TF
Technical findings
Affected function, conditions, evidence, impact and practical remediation.
BL
Business-logic findings
Abuse sequence and intended-versus-actual application behaviour for workflow issues.
RP
Remediation guidance
Specific control improvements for authorisation, validation, session handling or application design.
RR
Retest evidence
Verification of agreed fixes using the same role and attack condition where possible.
Remediation and retesting
Retesting reproduces the original request, role and abuse condition after the application change.
Damocles can retest agreed findings against the repaired release and record whether the original weakness is resolved, partially reduced or still exploitable.
New features and materially changed workflows can be added as new assessment scope when they extend beyond the original finding or release boundary.
Testing delivery
A controlled technical engagement without turning the service page into a methodology manual.
The commercial scope comes first. Delivery is then controlled through written authority, agreed safety boundaries and a clear retest path.
01
Scope and authorise
Confirm targets, ownership, attacker perspective, accounts, exclusions, timing, contacts and prohibited activity.
02
Test and validate
Perform the authorised manual and technical testing required to prove or disprove the attack paths in scope.
03
Report and brief
Provide evidence, impact, affected scope, remediation priorities and a technical walkthrough with the people responsible for the fix.
04
Retest
Reproduce agreed findings after remediation and record whether they are resolved, reduced or still exploitable.
Scope boundaries
The assessment covers the agreed application, roles and functions—not every connected platform by default.
Source-code review, mobile application testing, API-only testing, cloud configuration and third-party SaaS components are separate scope unless expressly included.
Production-impacting activity, destructive data changes and high-risk account actions are controlled through the agreed rules of engagement.
Scope the right test
Tell us the application, roles, release and sensitive workflows that need to be tested.
We will define the accounts, application areas, environment, exclusions, evidence and retest allowance required.