1. Choose a representative question
Use an application behavior your team understands, such as access to another tenant’s invoice. Define the roles, allowed operations, environment, exclusions, and expected result. Get written permission before active testing. A familiar scenario makes unsupported conclusions easier to notice.
2. Ask how access is established
Have the vendor demonstrate the supported login method and identity context. Ask what happens when MFA, session expiry, an inaccessible route, or a missing account blocks progress. A blocked check should appear as a limitation; it should not silently count as tested coverage.
3. Inspect one finding end to end
Ask for the action, the relevant request and response, the identity and resource context, and the expected behavior. Then ask which evidence supports the claimed impact. A generated explanation is useful only when the underlying observation can be inspected and appropriately reproduced.
4. Find the boundary of automation
Who approves scope? Which actions need additional permission? What stops execution? Who can review or reject a finding? Ask to see the relevant controls and records. A declaration that humans are involved is less useful than a demonstration of the specific decisions they make.
5. Look for honest coverage accounting
Request the distinction between tested, blocked, excluded, and unsupported behaviors. Compare coverage against the agreed question rather than counting requests or findings. Large volumes can reflect repeated activity; they do not by themselves establish assessment depth.
6. Review a retest conclusion
Use a known change and check whether the retest revisits the original behavior with the right identities and environment. A result should state what no longer reproduces and what remains uncertain. It should not convert a successful scoped check into a universal security guarantee.
7. Check operational and commercial fit
Confirm credential handling, evidence access, model/subprocessor use, retention, deletion, deployment requirements, reporting, usage units, retests, and support terms. If a regional or regulatory requirement matters, obtain a specific contractual and technical answer.
A practical acceptance record
Write down the evaluation question, authorized scope, identities, demonstrated behavior, evidence inspected, limitations, and the person accepting the result. This creates an evaluation you can compare over time. Apply the same standard to Turix: request early access and bring your requirements.
Further reading
Authoritative references for the assessment concepts discussed here.