The Trust Services Criteria do not require a penetration test. Anyone who tells you they do is selling. What they do contain is CC4.1, whose points of focus name penetration testing as an example of the separate evaluations management is expected to carry out - and in practice auditors ask for one, inside the observation window, from somebody independent. That is the real requirement, and it is the one we scope against.
Three things, consistently. Scope narrower than the audit boundary - an application tested while the admin portal on the same backend was left out. Scanner output presented as a penetration test, which is recognisable in about thirty seconds from the way the findings are written. And a report from "our certified team" with no named tester, no methodology and no evidence per finding.
None of those is about price. A cheap test with a named lead tester, a named methodology, reproducible evidence and a retest will be accepted where an expensive one without them is queried. We build the report around what the auditor has to tick, because that is the document you are actually buying.
Built from your system description rather than from a template, because the boundary in that document is the boundary the auditor will check against.
The finding that most often appears, and the one auditors care about most.
Mapped to CC6.1 and CC6.6.
Mapped to CC7.1.
In scope by default, because it is inside the same boundary.
The part CC6.6 and CC7.1 reach that an application test does not.
Written for the auditor as well as for you.
Two questions before anything else, because both change the scope and the timing.
Two accounts at every role, which is what authorisation testing needs.
Manually, against the whole boundary, with access control first.
Two documents: one your engineers can work from, one your auditor can accept.
Before your window closes, not after.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows AICPA Trust Services Criteria, OWASP Web Security Testing Guide, OWASP API Security Top 10 and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our compliance and audit service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
No. The Trust Services Criteria do not mandate one. Penetration testing appears in the points of focus under CC4.1, as an example of the ongoing and separate evaluations management performs. In practice almost every auditor asks for one for a Type II, and a report dated inside the observation window is what they want. We would rather you heard that from us than discovered the nuance later.
Inside the observation window. A test dated before the window started is commonly queried, and one dated after it closed is no use for that report. Tell us your window and we will work backwards from it, leaving time for the retest.
Generally no. Type I is a point-in-time opinion on design, not operating effectiveness. Most organizations buying Type I do not need a penetration test for it, and we will tell you so rather than sell you one.
The report, the scope, the dates, who performed it and their independence, the methodology, and evidence that the serious findings were fixed. The retest closure summary is the piece most often missing, which is why it is in our price rather than beside it.
Yes. Those platforms track the control and hold the evidence; the testing is done outside them. We deliver the report and the closure summary in a form you can upload, and we are happy to talk to your auditor directly.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.