Security Reviews
A security review compares every written representation a company has made about security and data against what its systems actually do.
Why the review exists
Most companies have two separate descriptions of how they handle data. One lives in the company’s policies and agreements. The other is the infrastructure. The two drift apart, and the drift is usually invisible until an enterprise customer asks a specific question, an auditor flags an inconsistency, or a deletion request arrives that nobody can fulfill.
A company does not need a problem in front of it to commission the review. The most common reason to run one is simply to establish where the company stands: that what it has promised is what it does, that it is meeting its obligations, and that it can demonstrate as much if asked. A gap found on the company’s own schedule is a good deal easier to close than one found by a customer, an auditor, or a regulator.
A specific event often prompts the review as well. These are some examples:
- An enterprise customer sends a security questionnaire that cannot be answered accurately
- A SOC 2 or ISO readiness process surfaces gaps between policy and practice
- Diligence in a financing or an acquisition raises security and privacy questions
- A new AI tool has been deployed and existing customer agreements do not clearly cover it
- A customer’s legal team redlines a data processing agreement and asks questions the company cannot answer
- A deletion or access request arrives and the workflow does not exist
What the review covers
The contractual record. The review examines, among other things: the privacy policy, the terms of service, the data processing agreement template, customer DPAs, the security addendum, the published subprocessor list, trust center content, prior completed security questionnaires, vendor agreements, and any other agreements bearing on security or data.
The systems. Working with engineers retained by the firm, the review examines, among other things: data residency, encryption at rest and in transit, retention and deletion as actually implemented, access controls and logging, the subprocessor inventory, AI vendor configuration including retention and training settings, and whether data subject requests can be fulfilled within the committed timeframe.
How it works
A scoping call establishes the size of the engagement. The contractual record is then collected and a test list is built from it, so that each written commitment becomes something to verify. The technical review runs against that list. Every discrepancy is mapped to the specific contractual or public representation it contradicts, the findings are ranked by exposure, and a memorandum setting out recommended remediation follows.
Most engagements run four to six weeks. The technical work is usually performed remotely, but on-site work is available where infrastructure or security policy requires it.
Remediation
The memorandum sets out what should change, in the order legal exposure dictates rather than engineering convenience. Some findings are corrected on paper: a representation narrowed to what the company actually does, a subprocessor list brought current, a commitment given a remediation date instead of an unqualified promise. Others require a change to the systems, and those are written so that engineering can act on them without further translation.
Where the company wants it carried through, the firm drafts the revised agreements and public statements, prepares any amendments customers need to sign, and re-tests the technical findings once engineering reports them closed — so the record shows not only that a gap was identified but that it was closed, and when.
Fees
A flat fee, quoted before the engagement begins and fixed for the defined scope. The fee is scaled to the size and complexity of the company — the number of production environments, the number of subprocessors, and the number of agreements.