Bespoke Security Validation
Validation designed around a specific protection goal
We start from the harm your business worries about, and focus the testing on the paths that lead to it.
Business-logic abuse, apps that are easy to analyse or modify, personal data that could leak, separated networks that are not really separate: we take the threat you are worried about, follow the systems and operations around it, and confirm what can really happen and what it would cost. For each area we design the checks and scenarios; the result sets out, scenario by scenario, what got through, what was stopped, and why.
Can the harm we worry about actually happen?
We set out, scenario by scenario, the conditions under which it happens, its impact, and how to improve.
Reviewed
When it fits
- A harm to the business is the worry
You want to know whether worries such as ‘could coupons or points be misused?’ or ‘could our app be copied or modified?’ can really come true.
- You hold a lot of personal data or critical material
You want to know where customer data or core technical material is kept, and where it could leak.
- A new environment or technology is coming in
You're bringing in an AI agent, an LLM service or a new architecture and want to know whether the lines you've set, such as ‘nothing goes out without a person's approval’, really hold. Where no checklist exists yet, we design the method first.
Specialised validation areas
Each area starts from a worry in business or user terms and has its own checks. Areas can be combined, and a worry not listed here can be designed with you.
Business logic abuse
Can business rules such as coupons, points, refunds or bookings be used outside the normal procedure for gain?
- What we validate
- Price, quantity and discount calculations
- Payment, cancellation and refund flows
- Coupons, points and rewards used more than once
- Skipped processing steps and approvals
- Protection against bulk automated requests such as macros and bots
- Using features meant for another user's role
- A good fit for
- Commerce, bookings and ticketing, finance and points, games, subscription services
- A condition we might test
- ‘Once a payment is complete, its amount cannot change’
App and client logic protection
If someone analyses our app, how easily do its core logic and security features show, and can they be modified or bypassed?
- What we validate
- How hard the app or client code is to analyse
- Obfuscation and code protection
- Integrity checks and tamper detection
- Defences against rooted, jailbroken and debugging environments
- Whether API calls and internal protocols can be worked out
- Keys, settings and critical logic shipped inside the app
- How well payment, authentication and licence logic are protected
- A good fit for
- Games, finance apps, mobile services, IoT and smart devices, paid services
- A condition we might test
- ‘A modified app cannot use payment or sign-in features’
Personal and sensitive data exposure
Where does personal and sensitive data stay, and where could it leak?
- What we validate
- What personal and sensitive data is collected
- How it is stored in apps, servers and the cloud
- How it travels over APIs and the network
- Logs, error messages and debug output
- Caches, temporary files and backups
- Data in URLs, the browser or inside the app
- Whether users without permission can reach it
- Share links and storage left open
- Access still held by leavers and dormant accounts
- Data left behind after retention periods or deletion
- Small pieces that combine into sensitive information
- A good fit for
- Personal, payment or health data, large customer datasets, organisations under privacy rules
- A condition we might test
- ‘Personal data does not reach the analytics environment without pseudonymisation’
The focus is technical exposure and misuse, not a judgement of legal compliance.
Network separation and data exfiltration control
Is what we believe is separated really isolated, and is there any way for critical material to leave?
- What we validate
- Whether network separation and segmentation hold as designed
- Boundary controls between development, production and external networks
- Whether critical documents and data can be gathered in bulk
- Routes out of the organisation, and how far controls cover them
- Controls on VDI, remote work and file transfer
- Whether DLP and firewalls actually catch exfiltration
- A good fit for
- Separated networks (finance, public sector, defence), core technology and design material, insider-leak concerns
- A condition we might test
- ‘Design files cannot be moved out of the business network’
Tenant and system isolation
In a service many client companies share, can one company's data or functions cross over to another?
- What we validate
- Separation of data, files and search between client companies
- How far admin and support functions reach
- Trust between systems and services
- Isolation on shared infrastructure
- Permissions handed to connected services
- A good fit for
- B2B SaaS, platforms, systems shared across group companies
- A condition we might test
- ‘One client company's data is never visible to another’
Protection conditions for AI and new technology
Does an AI agent or a newly adopted architecture actually stay inside the lines we have set?
- What we validate
- The agent's tool permissions and where approval is required
- How outside input affects actions and answers
- Data leaving through the model
- How output is handled when it goes on to other systems
- Records of actions, and tracing them
- Protection conditions for technology without a checklist, such as embedded devices or new protocols
- A good fit for
- Bringing in AI agents or LLM services, launching a new architecture or technology
- A condition we might test
- ‘The AI agent sends nothing outside without a person's approval’
What bespoke validation does differently
It starts from business harm
Not a list of techniques, but harms that reach the business: money lost, data leaked, a service abused.
It looks the way an attacker analyses
We take the app and service apart as an attacker would, and see how easily the core logic and data come into view.
It has checks for each area
Logic abuse, app protection, personal data, network separation, AI: each area uses checks designed for it, combined to fit your worry.
It reports by harm
For each scenario: whether it got through or was stopped, under which conditions, and what it would mean for the business, with the evidence.
How it runs
Where it helps, we run it as a Scenario-Based Penetration Test.
Set the question
Pick the harm you worry about, then the condition that must hold to prevent it and what it would mean if it failed.
Design conditions and method
We choose a method that fits the technology and business flow, and agree the accounts, environment and information it needs.
Agree safety conditions
Permitted and prohibited actions, stop conditions and the test environment are agreed before we start.
Validate
We check with the designed method and, where useful, follow a scenario through to see whether it really gets through.
Explain the results
For each scenario, whether it was stopped or got through, with the evidence, business impact and how to improve.
What you receive
Results by scenario
For each scenario: whether it was stopped or got through, and the conditions that make it so.
Business impact
What each result would mean in money, data and service terms.
Evidence
The steps and proof needed to reproduce what we found.
Improvement and what was not covered
How to improve, and which parts this design did not examine.
A coupon or points can be used only once, under the set conditions
Area: business logic abuse · Target: a commerce app and its order and payment APIs
| Scenario | Result | Evidence |
|---|---|---|
| Normal order and payment | Stopped | The server recalculates the discounted amount itself. |
| Cancellation overlapping with reuse | Got through | The same coupon can be applied a second time. |
| The price the app sends | Stopped | The price sent by the app is ignored; payment uses the server value. |
| Referral points | Needs work | Points build up with every new account, with no limit and no check for bulk sign-ups. |
- Business impact
- Discounts paid out more than once, and promotion budgets spent on accounts created only for points.
- How to improve
- Handle coupon use and restoration as one step; add identity checks, payout limits and checks for bulk sign-ups to referral points.
It does not replace a certification audit or legal advice. A re-test after fixes is agreed separately.