Requesting account
OUR APPROACHScope the question.
Scope the question.
Verify the fix.
Agree on the systems and boundaries, investigate the risk, and make the evidence clear. We help your team act on the findings and define the follow-up verification together.
Get a quote See how the work takes shape
SecurityWeb application assessment
Define the accounts, the resource and the boundary to test.
Two isolated test accountsOwnership checks
Resource owner
Birch
Protected resource
Invoice 2048
- Owner
- Birch
GET
/api/invoices/2048 Authentication Account boundaries Retest criteria
A CLEAR STARTING POINTPrepare the scope.
Prepare the scope.
Keep the boundaries clear.
Systems in scope
Applications, APIs and environments to include.
Test access
Test accounts and the permissions each role should have.
Testing window
Agreed timing, contacts and rules of engagement.
HOW THE WORK TAKES SHAPEFrom finding
From finding
to a verified fix.
See the work at each stage, what we check, and what your team takes forward.
Know exactly what is being tested.
Agree the systems, access and boundaries before the first test.
Web application assessment / Scope
- Application
- Web application and Invoice API
- In scope
- Test access
- Two accounts with different owners
- Required
- Focus
- Account boundaries and private records
- Defined
Security
Follow the evidence.
Trace the request, reproduce the finding, and check the ownership boundary after the fix.
What information helps us start?
Tell us what you want to improve, who will use it, which tools or systems are involved, and your timing. Share any existing content or examples. A complete technical specification is not needed to begin.
Can you work with our existing tools?
Your current tools and processes are the starting point. We review the available integrations, access and technical constraints before proposing changes, and explain any dependencies that affect the scope.
What if the scope changes?
We make the change visible, explain its effect on the agreed work, and decide the next step together. New requirements can be prioritised, exchanged for existing scope or agreed as additional work.
What happens after handover?
Documentation, access and any training are agreed as part of the engagement. Ongoing support, further development and security retesting can be scoped separately, with a clear owner for the next action.
A USEFUL NEXT STEP
What needs to work better?
Tell us what you want to change and what you already have. We’ll work through a useful starting point.