Map services to dependencies
A support application can become an entry point to CI credentials and an overprivileged payment identity. A separate signing service may still prevent release. A useful assessment explains each transition instead of turning one vulnerable host into a claim that the entire bank was compromised.
List the business or care services first, then map the applications, identity systems, networks and providers that support them. Record which owner can authorise each component. A domain count alone cannot describe the permission boundaries or operational consequences.
Prepare roles and representative data
Supply dedicated identities with documented roles and known expected permissions. Use more than one tenant, customer or organisational unit where boundaries are part of the objective. Label canary objects so testers and owners can distinguish them from real records.
Choose the assessment areas
- Digital banking & API penetration testing: Account ownership, delegated authority and transaction state create a richer permission model than login alone. Alternate APIs, exports and back-office functions need the same business rules.
- Bank network & privileged identity testing: Management exceptions, build artefacts and shared service roles can bridge otherwise separate zones. The important result is the authority obtained at the end of a path, not just the number of hosts reached.
- Payment workflow & authorisation testing: A maker-checker control can appear correct in the user interface while a service principal can call both operations. Token audience, operation scope and transaction version need to remain bound to the business policy.
Agree the test conditions
Use seeded payments and synthetic customers with settlement disabled. Agree independent stop authority, transaction reconciliation, named system owners and permission for third-party services. Separate demonstrated draft changes from unperformed fund transfers.
- Named test sources, destinations and permitted interfaces.
- Approved time windows, rate limits and excluded methods.
- Third-party consent, control contacts and stop authority.
- Evidence handling, cleanup, reporting and retest responsibilities.
Keep changes visible
Record material releases, new routes and permission changes during the test. If an unexpected path reaches a system outside the authorised boundary, pause and resolve scope through the named decision maker. Record untested dependencies in the final coverage statement.
