Architecture review or penetration test first?

Start from what is changing

If a customer wants a pentest report by the end of the quarter, buy the pentest. If you’re about to go multi-tenant or open an API to partners, a pentest of today’s product says little about next quarter’s. Get the design reviewed while it is still cheap to change.

The two answer different questions. A penetration test shows what an attacker can do to the running system, inside an agreed scope. An architecture review asks whether the design keeps each customer’s data apart, including from your own support tools and background workers.

What an architecture review examines

We’d pick one real flow and follow it. Say a customer exports their invoices and a background worker builds the file. Where does the worker get the customer ID from, and could anything change it on the way? Suppose the worker logs in to the database with an account that can read every customer’s invoices, because that was quickest at launch. A test of the web app is unlikely to reach it. A design review starts there.

What a penetration test is better at

A pentest earns its fee on a stable product where someone needs evidence about the live system. It shows whether a weakness can actually be used, with steps your engineers can repeat. Read the scope page before the findings. Admin tools and anything shipped after the test dates are often outside it.

Which to buy first

If pentests keep finding the same kind of issue, the pattern is a design question, so commission a review of it. If the last pentest was clean and you have added integrations since, start the review with what the test never saw.

For a product about to go multi-tenant, we’d buy the review first and test the new design once it’s live.