Most marketing intelligence platform evaluations end the same way: the security review clears, the stakeholders are aligned, and then someone asks how long the data integration takes. The answer, six to eighteen months of data engineering, a custom data warehouse, a dedicated infrastructure team, kills more GTM platform deployments than any security concern.
The architecture is the risk, not the compliance documentation. The security review is the easy part.
Lative was built to eliminate that category of problem entirely. Lative’s platform and security model is built on a serverless data warehouse architecture: no hardware provisioning, no custom data model design, no infrastructure team required. The security review leads directly to activation, not to a year-long build project.
- Prerequisites: CRM and marketing automation requirements before integration begins
- Data access model: how Lative connects to your systems and what permissions the integration requires
- Encryption: data protection in transit and at rest
- Customer isolation: whether compute and data environments are shared or fully independent
- Monitoring: how security events and anomalies are tracked in real time
Platform architecture
For revenue operations and marketing teams completing a security review, the questions are consistent across every evaluation. Here is what each area covers:
Lative’s platform architecture is designed around one principle: eliminate the infrastructure work that typically sits between a security clearance and actual platform use. The questions below cover architecture decisions, setup time, CRM prerequisites, and the access model the integration uses.
When AskNicely completed their security review and connected Salesforce, they were running live demand engine views within the same week. Their team completed field mappings without needing a data engineering resource or a dedicated infrastructure project. That timeline is the norm, not the exception.
Why a serverless data warehouse?
The serverless architecture exists to get marketing out of the business of building and managing custom data infrastructure. Segment’s 2022 State of CDP report found that 62% of enterprises spend over $100,000 building custom analytics platforms, investment that diverts marketing resources away from demand generation and toward infrastructure maintenance.
Lative eliminates that cost entirely. There is no development work, no hardware provisioning, no scalable architecture to design. The platform handles the data model; the team focuses on the GTM work.
OpenView’s 2023 SaaS Benchmarks report, based on 710 operators, found that AI-native companies are 3.3 times more likely to be growth outliers than their non-AI-native peers. The prerequisite for that advantage is clean, connected GTM data, and the most common barrier to that foundation is the infrastructure burden the serverless architecture removes.
How long does setup take?
The platform can be operational in less than a day. Setup primarily involves field mappings. Lative guides customers through each step required for onboarding, and support is available throughout the process.
What are the prerequisites?
Lative requires Salesforce as the CRM (Professional edition or higher, with API access). Marketing automation systems supported alongside Salesforce include Marketo, HubSpot, and Salesforce Marketing Cloud. Salesforce system administrator access is required during setup to configure the Connected App integration.
How does the Salesforce connection work?
Lative connects to Salesforce using OAuth 2.0, the industry-standard authorization protocol. The connection is read-only: Lative accesses data via REST API requests only. All data is encrypted in transit and at rest. Lative does not write to your CRM or marketing automation system at any point. There is no two-way sync.
Who can access the platform?
The platform is designed to give every stakeholder who needs marketing intelligence, CMO, RevOps, finance, sales leadership, access to the same data without seat negotiations or license constraints. There is no per-user pricing and no headcount-based monetization. All users authenticate with issued credentials via encrypted transport layer.
Security architecture
Lative’s security architecture runs on Amazon Web Services, with customer isolation, encryption, and monitoring configured at the infrastructure level. The components below cover what a standard security review will examine across isolation, encryption, physical hosting, monitoring, and the software development lifecycle.
Isolated customer environments
All customer compute and data resources are isolated using Amazon cloud infrastructure. Each customer gets a completely independent environment with no shared tenancy between customers.
This eliminates the risk of unauthorized cross-customer access whether accidental or malicious. Amazon’s infrastructure is assessed by third-party auditors as part of multiple AWS compliance programs including SOC, PCI, FedRAMP, and HIPAA.
Data encryption
All data is encrypted at rest and in transit. Lative does not host any services or store any data outside of its secure cloud computing environment.
Datacenter security
Lative deploys on Amazon Web Services (AWS) for infrastructure hosting. AWS provides high levels of physical and network security. AWS maintains an audited security program with SOC 2 and ISO 27001 compliance. All instances reside in US locations.
Real-time monitoring
Lative monitors Amazon CloudWatch Logs to track applications and systems in real time. All activities are logged. Security events and potential threats trigger proactive response. The monitoring infrastructure ensures no suspicious activity goes undetected.
Software development lifecycle
Lative adheres to a secure software development lifecycle (SSDL), applying security principles across design, implementation, deployment, and operations phases. Data storage uses highly durable infrastructure designed for mission-critical and primary data storage, with objects redundantly stored across multiple regions.
Most GTM platform security reviews surface one of three concerns that delay activation.
Data Residency: US-Only AWS Locations
The first is data residency: where customer data lives and whether it leaves the United States. Lative’s infrastructure runs on AWS in US-only locations.
Write Access: Read-Only Salesforce Connection
The second is write access: whether the platform can modify or delete CRM records. Lative’s Salesforce connection is read-only, configured via OAuth 2.0 with REST API access only. It cannot write to your CRM at any point.
Tenant Isolation: Independent Environment Per Customer
The third is tenant isolation: whether one customer’s data is accessible to another customer in a shared environment. Lative provides a fully independent compute and data environment per customer. No data, no processing, and no storage is shared between tenants.
How multi-tenant isolation and read-only access protect the CRM as system of record
A connected GTM analytics platform sits in a sensitive position. It reads pipeline, opportunity, and revenue data continuously, and any architectural shortcut on that connection becomes a risk that lands on the customer’s CRM administrator, not on the vendor. Lative’s architecture closes the two largest classes of risk by design: cross-tenant data exposure and unauthorized write access to the source CRM. The mechanism is a combination of multi-tenant isolation implemented as per-customer environments and read-only OAuth on the upstream connection.
Multi-tenant isolation: independent environments instead of shared schema
Many B2B SaaS platforms implement multi-tenancy as a shared database with a tenant identifier column. That model is cheap to operate and exposes a single class of catastrophic bug: any logic error in the tenant filter leaks one customer’s records into another customer’s view. Lative does not take that tradeoff. Each customer gets a fully independent compute and data environment on AWS, so there is no shared table, no tenant ID column to filter on, and no application-level enforcement to fail. The isolation is provisioned at the infrastructure layer, which is also the layer a security review can validate without reading application code.
The practical outcome for a CRM administrator: a deletion request, a data residency requirement, or a contract termination is executed against a single tenant boundary, not against a row filter inside a multi-tenant table. Tenant data can be removed without touching any other customer’s environment.
Read-only OAuth and the principle of least privilege
The Salesforce connection is configured through OAuth 2.0 with read-only scopes. This is the principle of least privilege applied to the upstream connection: Lative requests exactly the access required to read the records the analytics layer needs, and nothing else. There is no write scope, no delete scope, and no administrative scope on the Connected App. A bug in Lative cannot modify a Salesforce record. A compromised token cannot delete an opportunity. The CRM stays the system of record without any compensating control on the Salesforce side.
Revoking access is symmetric. The customer’s Salesforce administrator can revoke the Connected App grant from inside Salesforce, which terminates Lative’s ability to read further records on the next sync attempt. There is no separate de-provisioning workflow to coordinate with the vendor for the access cutoff itself.
Encryption at rest, encryption in transit, and key management
Encryption at rest covers data once it lands in Lative’s tenant data warehouse, applied at the storage layer under AES-256. Encryption in transit covers every API call between Salesforce, the marketing automation platform, and Lative under TLS 1.2 or higher. The two layers interact: data is encrypted on the wire from the moment it leaves the CRM, decrypted only inside the tenant’s isolated processing environment, then re-encrypted before it lands in long-term storage. There is no point in the pipeline where customer data sits unencrypted on a shared resource.
Key management runs inside the AWS-managed Key Management Service for each tenant environment. Rotation is automated on the AWS schedule, and the operational team does not have access to plaintext keys. For an enterprise security questionnaire, the answer maps directly to the AWS KMS shared-responsibility documentation the buyer’s security team has already evaluated for other cloud vendors.
For more on how the platform connects marketing intelligence to pipeline and revenue operations, see the Lative platform overview and how to build a world-class demand engine.
The same secure, read-only foundation serves both halves of Lative: marketing intelligence and sales capacity planning.
If the security review is the step between your team and a unified GTM data foundation, this is what the review will find. Talk to the Lative team about connecting your Salesforce data to revenue-grade marketing intelligence.
Key takeaways
- Multi-tenant isolation as independent per-customer environments removes the single-bug-leaks-everything failure mode that shared-schema multi-tenancy carries. The isolation is enforced at the AWS infrastructure layer, not in application code.
- Read-only OAuth on the Salesforce connection makes the CRM-as-system-of-record guarantee architectural. There is no write path Lative could take even if requested, so the source CRM stays under the customer’s control by construction.
- Principle of least privilege is implemented at the scope level, not at the policy level. The Connected App grants exactly the read access the analytics layer needs, which is what a security team can verify directly in Salesforce.
- Encryption at rest under AES-256 and encryption in transit under TLS 1.2+ work together so customer data is never sitting unencrypted on a shared resource at any stage of the ingestion or query pipeline.
- Key management runs inside AWS KMS per tenant environment with automated rotation, so the operational team never touches plaintext keys and the rotation cadence does not depend on a manual process.
Frequently asked
What does multi-tenant isolation look like in practice on Lative?
Each customer gets a fully independent compute and data environment on AWS, rather than a shared database with a tenant identifier column. There is no shared table that contains records from multiple customers, which is the architectural pattern that removes the single largest class of multi-tenant security failure: a logic bug in the tenant filter that exposes one customer’s data to another. Tenant boundaries are enforced at the AWS infrastructure layer, so a security review can validate the isolation against AWS account and resource scoping without reading any application code.
Why does Lative use a read-only OAuth scope instead of a service account with broader access?
Read-only OAuth applies the principle of least privilege to the upstream connection. The Connected App requests exactly the read scope the analytics layer needs, with no write, delete, or administrative permissions. A broader service account would create a write path Lative does not use, which is a class of risk a security team would have to monitor and compensate for. Removing the write scope removes the risk by construction, which is why most enterprise security reviews of Lative close quickly on the access-model question.
How do encryption at rest and encryption in transit interact across the ingestion pipeline?
Data is encrypted on the wire from the moment it leaves Salesforce under TLS 1.2 or higher, decrypted only inside the customer’s isolated processing environment, then re-encrypted at AES-256 before it lands in tenant storage. The two layers are designed so customer data is never sitting unencrypted on a shared resource at any stage. Key management runs inside AWS KMS for each tenant environment, with automated rotation on the AWS schedule and no operational access to plaintext keys, which is what the AWS shared-responsibility documentation already covers for the customer’s broader security review.
Lative Team — Lative is the AI-native GTM platform that connects marketing intelligence to sales capacity planning on one shared data foundation.
