Security and Compliance Checklist for Evaluating a Revenue Platform
Callia Peterson

Yes. Enterprises should evaluate security and compliance before capability, because a revenue platform that fails review cannot be deployed regardless of its results.
A revenue platform holds CRM records, prospect contact data, deal history, and email content, and AI features add three questions that standard SaaS reviews miss: whether your data trains the vendor's models, whether outputs can be traced to inputs, and which sub-processors receive your data.
Use the checklist below as a pass/fail gate, then run the capability evaluation on vendors that pass.
Why should security come before capability?
Security review is a gate, not a tiebreaker. A platform that clears the gate can move to a pilot. One that fails stops there.
Evaluating in the other order creates a predictable problem. The sales team commits to a platform, then information security, legal, and procurement find gaps and the deal stalls.
Rox's enterprise AI data governance guide recommends this sequence:
Security and governance baseline. Pass or fail.
Integration architecture. CRM sync, identity management, data warehouse, and email compliance.
Capability and ROI. Account intelligence, signal quality, forecasting, and measured pipeline impact.
What data does a revenue platform handle?
Data type | Examples | Why it matters |
|---|---|---|
CRM records | Accounts, contacts, opportunities, notes | Contains customer and pipeline data |
Prospect data | Names, titles, emails, phone numbers | Personal data under GDPR and similar laws |
Communications | Email content, call recordings, meeting summaries | May include confidential and personal information |
Deal intelligence | Stage history, forecasts, win and loss reasons | Competitively sensitive |
Credentials and tokens | OAuth access to CRM, email, calendar | Broad access if compromised |
What is the security and compliance checklist?
Score each item as Pass, Fail, or Not provided. Treat any Not provided on a critical item as a Fail until the vendor supplies evidence.
Section 1: Certifications and independent assurance
# | Check | Evidence to request | Critical |
|---|---|---|---|
1 | SOC 2 Type II report is current | Report under NDA, with audit period, scope, and exceptions | Yes |
2 | Report covers the systems you will use | Scope section of the report | Yes |
3 | No significant exceptions or qualified opinion | Auditor's opinion page | Yes |
4 | ISO 27001 certificate, if your policy requires it | Certificate and scope statement | Depends on policy |
5 | Third-party penetration test in the last 12 months | Executive summary or letter of attestation | Yes |
6 | Vulnerability management process documented | Policy and remediation timelines | No |
SOC 2 Type I confirms controls exist at a point in time. Type II confirms they operated effectively over a period, usually about 12 months. Sources differ on how old a report may be.
One AI vendor checklist treats reports older than 12 months as stale, while Rox's governance guide treats reports older than 18 months as potentially stale. Set your own threshold and ask for a bridge letter if the report is aging.
Section 2: Data protection
# | Check | Evidence to request | Critical |
|---|---|---|---|
7 | Encryption in transit and at rest | Security whitepaper or trust center page | Yes |
8 | Customer data isolation in a multi-tenant system | Architecture description | Yes |
9 | Data residency location confirmed and contractually bound | Written commitment and transfer mechanism for EU data | Yes, for regulated data |
10 | Retention periods defined | Retention schedule | Yes |
11 | Deletion at termination, with confirmation | Written deletion procedure and certificate | Yes |
12 | Backups and disaster recovery tested | Recovery objectives and last test date | No |
Section 3: Access and identity
# | Check | Evidence to request | Critical |
|---|---|---|---|
13 | SSO through SAML 2.0 | Product documentation | Yes |
14 | Multi-factor authentication enforced | Admin settings | Yes |
15 | Role-based access control at the data layer | Demonstration in a trial, including through the API | Yes |
16 | Vendor staff access to customer data restricted and logged | Access policy and sample log | Yes |
17 | Immutable audit logs, exportable to your SIEM | Log schema and retention period | Yes |
Application-layer access control hides data in the interface. Data-layer control enforces the restriction however the data is reached, including by API and export.
Ask the vendor to show a user in one territory failing to reach another territory's records by every route.
Section 4: AI-specific governance
# | Check | Evidence to request | Critical |
|---|---|---|---|
18 | Customer data is not used to train or fine-tune models | Contract language, not a sales statement | Yes |
19 | AI outputs can be traced to inputs | A live example of a score or alert with its source signals | Yes |
20 | Platform reads only the CRM fields it needs | Data access map and field-level configuration | Yes |
21 | Full sub-processor list, including LLM providers and enrichment vendors | Current list and change notification process | Yes |
22 | Right to object to new sub-processors | DPA clause | Yes |
23 | Human review controls for outbound messages | Approval workflow and auto-send settings | Yes |
24 | Protection against prompt injection and data leakage | Test results or architecture description | No |
25 | Guardrails on what an agent can do | Permission model for agent actions | Yes |
Training on customer data creates two exposures. Cross-contamination means patterns from your data may influence outputs for other customers, possibly competitors.
Deletion risk means removing raw data at termination does not remove its influence from a trained model.
Section 5: Contracts and privacy
# | Check | Evidence to request | Critical |
|---|---|---|---|
26 | Signed Data Processing Agreement before sharing personal data | DPA | Yes |
27 | Breach notification timeline in the contract | Clause with a stated number of hours | Yes |
28 | Audit rights | Clause | No |
29 | Termination right for security failures | Clause | No |
30 | Data subject request handling | Procedure and turnaround | Yes, for EU data |
31 | Liability caps and indemnity reviewed by counsel | Master agreement | Yes |
32 | Cyber insurance confirmed | Certificate | No |
Under GDPR, controllers must notify the supervisory authority of a personal data breach within 72 hours of becoming aware of it, so a processor's contract should commit to notifying you well inside that window. Have counsel set the exact figure.
Section 6: Outreach compliance
A revenue platform that sends email or makes calls adds compliance exposure on top of data security.
# | Check | Why |
|---|---|---|
33 | Opt-out handling and suppression lists | CAN-SPAM, GDPR, and similar laws |
34 | Consent capture and storage for calls and texts | TCPA rules, including for AI-generated voices |
35 | Sending limits and domain reputation controls | Protects deliverability |
36 | Source of contact data documented | Lawful basis for processing |
See cold outreach compliance for the outreach side. This is general information, not legal advice.
What red flags should end the evaluation?
Red flag | Why it matters |
|---|---|
No SOC 2 or equivalent assurance | Baseline controls are not demonstrated |
Refuses to share a DPA or data handling terms | Transparency gap on core questions |
Trains on your data without an opt-out | Your data improves their product for others |
Vague answers on security questions | A vendor with strong controls can describe them |
No sub-processor list | You cannot assess where data goes |
No penetration test history | Vulnerabilities may be undiscovered |
Resists a security questionnaire | Mature vendors expect one |
Verbal assurances where a contract clause is needed | Only written terms bind the vendor |
Which questions should you ask every vendor?
Does the platform use our data to train, fine-tune, or improve models? Where is this written in the contract?
What is the complete sub-processor list, and how will you notify us of changes?
For a given AI recommendation, which data inputs produced it? Show an example.
Which CRM fields does the platform read, and can we restrict them?
Can we review your latest SOC 2 Type II report, including scope, period, and exceptions?
What is the contractual breach notification timeline?
How is our data deleted at termination, and what confirmation do we receive?
These follow the seven-question set in Rox's governance guide.
How does Rox answer these checks?
Rox publishes its security posture at rox.com/security, a Trust Center, and a public subprocessor list. Per Rox's site:
Rox lists SOC 2 Type I, SOC 2 Type II, and GDPR compliance on its security page.
ISO 27001 is listed as coming soon, not as a current certification.
Customer data is encrypted in transit and at rest using AES-256.
Customer data is never used to train generalized machine learning models.
Rox states that it undergoes independent third-party security audits annually.
AI outputs are provided for informational purposes and should be reviewed by authorized personnel before action. Features described as automated operate within user-defined parameters and require configuration and ongoing oversight.
Rox's governance guide says its AI generates recommendations from retrieved account context rather than from training on customer data, and that its security materials include a SOC 2 Type II report under NDA, a DPA with a sub-processor list, data residency documentation, and responses to standard questionnaires such as CAIQ and SIG.
Request these documents during evaluation and verify them against your checklist. Rox integrates with Salesforce, HubSpot, Gmail, Microsoft Outlook, Slack, and other services, and the availability of those integrations depends on each provider's terms.
How do you run the evaluation in four weeks?
Week 1: Send the security questionnaire and request the SOC 2 report, DPA, sub-processor list, and penetration test summary under NDA.
Week 2: Have information security review documents against the checklist. Have legal mark up the DPA and breach terms.
Week 3: Test access control, SSO, audit logs, and approval workflows in a sandbox with synthetic data.
Week 4: Score each vendor, record exceptions with owners and dates, and decide who advances to a capability pilot.
Repeat the review annually and after major vendor changes such as an acquisition, a new sub-processor, or a new AI feature.
How should you score vendors?
Result | Action |
|---|---|
All critical items pass | Advance to the pilot |
One or two critical items not provided | Hold until the vendor supplies evidence by a set date |
Any critical item fails | Eliminate or require contract remediation approved by security and legal |
Several non-critical items fail | Advance with a written remediation plan |
FAQ
Should enterprises prioritize security and compliance when evaluating a revenue platform?
Yes. The platform handles CRM data, prospect personal data, and deal intelligence, and AI features add risks around model training, output traceability, and sub-processors. Treat security and governance as a pass or fail gate before the capability evaluation.
What certifications should a revenue platform have?
SOC 2 Type II is the usual baseline for enterprise procurement. ISO 27001 matters if your policy requires it. Request the report under NDA and check the scope, audit period, and exceptions.
Can a revenue platform use my data to train its AI models?
Only if the vendor and contract allow it. Require a written commitment, and ask how isolation is maintained and how data is removed on termination.
What is a sub-processor, and why does it matter?
A sub-processor is a third party that processes your data for the vendor, such as an LLM provider or an enrichment service. You inherit their handling practices, so require a current list and notice of changes.
How long does a security review take?
Plan on about four weeks for document review, legal markup, and sandbox testing. Large enterprises may need longer.
Does a SOC 2 report guarantee the platform is secure?
No. It shows controls operated effectively during the audit period within a defined scope. Read the scope and exceptions, and add AI-specific checks that SOC 2 does not cover.
Similar Articles
We build with the best to make sure we exceed the highest standards and deliver real value.

