Home / Knowledge hub / Testing in production
Knowledge hub
Testing in production
Running security tests against the live app, with controls to avoid harm.
What it means
Testing in production means running security tests against the live application that real customers use, rather than a copy. It is done on purpose, with written permission and agreed limits, and not as an accident. The tester is an invited guest with a brief, not a stranger who found a way in.
Teams choose it when no copy exists, or when the copy differs too much to trust. Real configuration, real integrations and real scale only exist in one place, and some flaws, such as a misconfigured load balancer, appear nowhere else.
Why it matters
It finds what staging cannot, but it carries real risk. A test that floods a login form can lock customers out. One that creates orders can trigger shipments. A badly aimed test can trip your own incident response at 3am. The benefit has to be worth the care.
Done well, it also gives the most honest answer to the question 'can this be abused today?'. Done badly, it produces a breach report with your own tester named in it. The difference is preparation, written limits, a named contact on both sides and an agreed way to stop the test the moment something looks wrong.
How it shows up
Agree the rules first: which hosts, which hours, which actions are forbidden, what rate of requests is allowed, and who to call if something looks wrong. Use test accounts and test data you control, and avoid destructive actions such as deleting records or sending messages. See rules of engagement.
Tell the people who watch your monitoring, or at least agree how test traffic is recognised, so an alert is not mistaken for an incident or the reverse. Prefer read-only proof where possible, and stop when a finding is confirmed rather than pushing further. Keep a log of what was sent.
Questions people ask
Testing in production, answered
Is it safe to pentest a live system?
It can be, with limits on rate, actions and hours, test accounts, and a named contact. Without those it is not.
Many teams test a copy first and run a narrower live pass afterwards.
Do we need permission to test in production?
Yes, in writing, from whoever owns the system. Cloud and hosting providers may also have their own rules about testing.
Testing a system without authorisation can be a crime in many countries.
Will testing in production cause downtime?
It can if requests are heavy or a flaw is destructive to exploit. That is why rate limits, careful payloads and a stop signal are agreed first.
Most live tests cause no outage when planned.
Should we tell the security team?
Usually yes, or at least a small group. Otherwise they may spend hours on a response to test traffic.
Some organisations run an unannounced test on purpose to test detection. That is a separate, agreed exercise.
What about customer data?
Use your own test accounts. If a flaw exposes real records, record that it does and stop, rather than reading or saving them.
The report should hold enough proof to fix the problem and no more personal data than that.
Sources
Where this comes from
Related
Terms that sit next to this one
Test environment
A copy of your app used for security testing so production is not at risk.
Rules of engagement
The agreed limits, times and contacts that govern how a security test is run.
Penetration test scope
The written list of what a pentest may and may not touch.
Penetration test
A time-boxed engagement where skilled people attack your systems by hand.
Logging and monitoring
Recording what happens, and actually watching what gets recorded.
Can live testing be kept safe?
Where live testing is agreed, we work to your scope and report what we actually exploited, with the request and response. If we did not break it, we do not report it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.