When you want to connect Lative’s Marketing Intelligence platform to your CRM and marketing automation stack, someone in IT or legal is going to ask three platform security questions: where does the data go, who can see it, and what happens if something goes wrong. This post answers those questions directly, in the terms a security review team actually uses.
Marketing intelligence platform architecture: how the data foundation works
Lative’s platform security architecture covers five areas a standard security review will examine:
- Authentication: OAuth 2.0 with Salesforce, read-only REST API access, no write permissions to any connected system
- Encryption: all data encrypted in transit (TLS) and at rest across all storage layers
- Tenant isolation: each customer runs on a fully independent compute and data environment within AWS
- Monitoring: Amazon CloudWatch Logs with real-time alerting on security events and anomalies
- Compliance: AWS infrastructure with SOC 2, ISO 27001, and FedRAMP audit coverage
Lative’s platform security is built on a serverless data warehouse architecture. There are no servers to patch, no fixed infrastructure footprint to maintain, and no single point of failure at the compute layer.
The data warehouse scales automatically with query load and data volume, so a marketing team running analysis on 18 months of CRM history and a concurrent quarterly board report do not compete for the same resources.
AWS Infrastructure and Shared Responsibility
The entire platform runs on Amazon Web Services (AWS). AWS handles physical security, network infrastructure, and hardware redundancy. Lative operates at the application and data layer on top of that foundation.
The underlying infrastructure compliance posture, including AWS’s SOC 2, ISO 27001, and PCI DSS certifications, applies at the infrastructure level and is available via AWS’s shared responsibility documentation.
Authentication and access control
User authentication uses OAuth 2.0, the industry-standard authorization protocol. Lative does not store user passwords. Access tokens are issued, scoped, and expired according to OAuth 2.0 grant flows, which means credential management happens through your existing identity provider rather than through a separate Lative account system.
Single Sign-On (SSO) via your organization’s existing IdP can be configured for enterprise accounts.
Data access within the platform follows role-based access control (RBAC). Your RevOps analyst accessing funnel data sees a different scope than someone running board-level pipeline analysis. Access is scoped to the data a role actually needs, not to the full data lake.
This matters when finance and marketing are both operating on the same platform: your CFO’s financial modeling view does not expose the individual-level lead data that lives in marketing’s operational reports.
Data encryption
All data is encrypted at rest using AES-256, the same encryption standard used by financial institutions and government agencies for sensitive data storage. All data in transit is encrypted using TLS 1.2 or higher, covering every API call between your CRM, marketing automation platform, and Lative’s data warehouse. There is no window where customer data travels unencrypted between systems.
Encryption keys are managed separately from the data they protect. A key compromise does not expose data, and a data exposure does not expose keys.
Compliance posture
SOC 2 Type II certification is the standard by which enterprise software buyers evaluate whether a vendor’s security controls actually work over time, not just on the day an auditor visits. SOC 2 Type II covers the five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
ISO 27001 certification covers the organization’s information security management system, including how security risks are identified, assessed, and treated across the full organization, not just the technical stack.
Infrastructure monitoring runs continuously via AWS CloudWatch, with real-time alerting for anomalous activity, performance degradation, and security events. Incidents are logged, escalated, and tracked through a defined response process, not managed ad hoc.
Secure software development lifecycle (SSDL)
Lative follows a Secure Software Development Lifecycle (SSDL) process, which means security review is built into how the platform is built, not applied after the fact. Code changes go through automated security testing, dependency vulnerability scanning, and peer review before they reach production. Penetration testing is conducted on a defined schedule.
Third-party dependencies are tracked and updated according to a vulnerability management process. When a critical CVE affects a dependency in the stack, remediation is tracked against a defined SLA, not left to the next release cycle.
Data model integrity: why revenue-grade accuracy matters for security
Most security reviews focus on access control and encryption. The data integrity question is equally important for a revenue intelligence platform: can you trust that the numbers the platform produces are accurate, and can you verify them?
Lative’s data model uses bi-temporal data architecture, which records both what was true at any point in time and when that fact was recorded. Every pipeline figure, every conversion rate, and every attribution calculation is traceable back to the underlying records that produced it.
An executive who questions a pipeline coverage number can drill to the individual opportunity records behind it and see exactly how the calculation was made. There is no black-box aggregation layer that produces a figure that cannot be audited.
This is both a trust argument and a compliance argument. For companies operating under revenue recognition standards or with board-level reporting obligations, the ability to trace an executive dashboard figure to an auditable source record is a requirement, not a preference.
Data privacy regulations and vendor security review
A platform that handles revenue data for an enterprise GTM team sits inside two regulatory frames: data privacy law in the jurisdictions where the company operates, and the customer’s own vendor security review process. Lative’s architecture is built to clear both without a custom integration.
GDPR and CCPA posture
GDPR compliance for a connected analytics platform comes down to four operational requirements: a lawful basis for processing personal data, contractual data processing terms between the customer and the platform vendor, the ability to honor data subject rights (access, correction, deletion, portability), and breach notification within 72 hours. Lative operates as a data processor on behalf of the customer, with a Data Processing Addendum (DPA) available on request and standard contractual clauses for any cross-border data transfer.
For California customers, CCPA and CPRA require equivalent control over how personal data flowing from the CRM is processed and retained. Because Lative connects to the source CRM through read-only OAuth 2.0 and does not write back, the customer retains full control of the system of record. A data subject deletion request executed in Salesforce or HubSpot propagates to Lative’s read view on the next sync cycle, not through a separate deletion workflow.
What the vendor security review actually checks
A vendor security review for a GTM analytics platform typically runs through six checkpoints: hosting and infrastructure compliance, encryption in transit and at rest, authentication and access control, audit logging and monitoring, third-party subprocessors, and incident response. Lative’s architecture has a documented answer for each of the six, packaged in the standard AWS-backed compliance bundle that an enterprise security team has already seen from other cloud vendors.
The practical outcome: most enterprise security reviews of Lative close in days, not weeks, because the architectural answers do not require custom legal or engineering work to produce. If the buyer’s questionnaire references SIG, CAIQ, or a proprietary template, the underlying control evidence maps directly to the SOC 2 Type II report and the ISO 27001 certification scope.
What this means for the security review
When Trulioo‘s IT and legal teams evaluated Lative as part of their onboarding review, the process completed in under a week with no custom compliance documentation required beyond the standard AWS certification package. The architecture answers the standard enterprise security questions before they are asked.
The short version for the security team: Lative runs on AWS with OAuth 2.0 authentication, AES-256 encryption at rest, TLS encryption in transit, role-based access control, real-time CloudWatch monitoring, and an SSDL process that treats security as a development requirement rather than a post-release audit. SOC 2 and ISO 27001 status should be confirmed with Lative’s team before vendor approval.
For you as the CMO bringing this into the executive conversation: this is the platform your CFO and legal team will sign off on, because it was built to meet enterprise security requirements from the start, not retrofitted to pass a review. For an overview of how the platform is structured, that post covers the full architecture and data model.
Security Review Holding Up Your Rollout?
That one foundation powers both marketing intelligence and sales capacity planning, so a single security review covers the whole platform.
If your security review process is the bottleneck between you and a unified GTM data foundation, talk to the Lative team about your specific requirements.
Key takeaways
- Read-only OAuth 2.0 access is the architectural decision that closes most enterprise security reviews early. There is no write path back to the CRM, so the system of record stays under the customer’s control and audit trail.
- AES-256 at rest and TLS 1.2+ in transit are the table-stakes encryption answers a security review expects. Lative carries both across every storage layer and every API call between the CRM, marketing automation, and the data warehouse.
- SOC 2 Type II and ISO 27001 together cover the controls a Fortune 500 security questionnaire asks about. SOC 2 Type II proves the controls work over time; ISO 27001 proves the security management system around them is documented and operating.
- Role-based access control plus audit logging answers the access-control half of the review. Finance, marketing, and sales each see the scope their role requires, and every query is logged for the customer’s own audit trail.
- GDPR compliance and CCPA posture come from the architecture, not from a bolt-on policy. The read-only connection to the CRM means data subject rights are honored upstream and reflected in Lative on the next sync, not handled in a parallel deletion workflow.
Frequently asked
Does Lative store customer CRM data or just query it in place?
Lative ingests data from the connected CRM and marketing automation platforms into its own serverless data warehouse on AWS, where it is stored encrypted at rest under AES-256 within an isolated tenant environment. Querying in place would not produce the historical bi-temporal accuracy the platform is built for. The connection itself is read-only OAuth 2.0, so Lative never has the ability to write to or modify the source CRM. If a customer revokes the OAuth grant, ingestion stops on the next sync attempt and the corresponding tenant data can be deleted on request under the standard DPA.
How does Lative handle a GDPR data subject deletion request?
The standard pattern is upstream first. A GDPR or CCPA data subject deletion is executed in the system of record (Salesforce, HubSpot, or the relevant marketing automation platform) by the customer’s data privacy team. Because Lative connects through read-only OAuth 2.0 and re-syncs against the source, the deleted record is removed from Lative’s read view on the next sync cycle. For records that need to be removed faster, or for tenant-wide deletion when a contract ends, the standard Data Processing Addendum defines the operational SLA and the verification steps Lative’s team executes against the tenant data warehouse.
What does Lative provide for an enterprise vendor security review?
The standard package covers the six checkpoints that show up in most enterprise security questionnaires: the SOC 2 Type II report under NDA, the ISO 27001 certificate, the AWS shared responsibility documentation for the underlying infrastructure, the Data Processing Addendum with standard contractual clauses, the subprocessor list, and an architecture summary that maps Lative’s controls to the customer’s questionnaire whether that is SIG Lite, CAIQ, or a proprietary template. The combination is designed to let an enterprise security team close out review without a custom legal or engineering workstream, which is why most reviews complete in under two weeks.
Lative Team — Lative is the AI-native GTM platform that connects marketing intelligence to sales capacity planning on one shared data foundation.
