- A security review reaches four roles, each asking for something different. Security engineers want technical controls, legal wants contract language, procurement wants certifications, and privacy officers want data residency answers.
- Execution logs and audit logs answer two different questions and get asked about separately. Execution logs show what an integration did; audit logs show what a person did, and reviewers want both to be immutable, timestamped, and exportable.
- SOC 2 Type 2 is usually a gate, not a differentiator, since most platforms that reach procurement already have it. What separates a fast review from a slow one is whether a vendor can also produce the audit report, bridge letters, and market-specific certifications like HIPAA, GDPR, or CJIS on request.
- A shared-responsibility model means the platform and the team each own different parts of the answer. The platform owns credential storage, execution isolation, and platform-level audit capabilities; the team owns what it builds on top, like how much OAuth scope an integration requests or what custom code logs.
Your champion loves the product. The demo went well. The trial worked. Then, three weeks before close, an email arrives from someone who wasn't in any of the earlier calls: a security analyst, a procurement lead, maybe someone your champion has never mentioned before. Attached is a 200-question spreadsheet, a request for a DPA, or a note that says, "Before we can move forward, we need to understand how you handle data.
That's the moment a lot of deals stall, because nobody on the deal team knows how to answer questions they've never had to answer before. And nearly every one of those questions goes back to the integration platform underneath your product.
Every integration involves you, your customers, your integration platform, the third-party apps being connected, and the platform's own subprocessors – including any AI providers. When you sell product integrations to your customers, you're also adjusting their risk profile. They know it, which is why their security team treats your integration layer with the same scrutiny they'd apply to any vendor with automated, credentialed access to their systems. Knowing those questions ahead of time, and knowing which ones your integration platform already answers for you, is the difference between a review that takes two weeks and one that takes two months.
Four roles care about integration security
The spreadsheet is the most visible part of a security review, but rarely does one person write or read it. By the time a deal reaches procurement, you're usually answering questions from people in four different roles, and each one is looking for something different:
| Who's asking | What they care about |
|---|---|
| Security engineer/CISO delegate | Technical controls for isolation, encryption, access, and logging. Penetration test results and vulnerability remediation SLAs. |
| Legal/compliance | Contract language for DPAs, sub-processor lists, and breach notification terms. Liability caps and cyber insurance. |
| Procurement/vendor risk | Certifications, audit reports, financial and operational stability |
| Data privacy officer (for regulated industries) | Data residency, retention limits and right-to-delete mechanics |
A platform can pass the technical review and still stall in legal, because nobody has a data processing agreement ready. It can clear legal and still stall with the privacy officer, because nobody can say where EU customer data physically sits. Treating the security review as one document, rather than four conversations happening in parallel, is a common failure.
The order matters, too. Most enterprise reviews follow a predictable shape: a questionnaire or RFP arrives first, then an architecture deep-dive with the security team, then a request for evidence (audit reports, diagrams, sample logs, sub-processor lists), and finally contract language covering liability, audit rights, and breach notification. Knowing which stage you're in tells you which of the four roles above you're talking to, and what they'll accept as an answer.
Security questions and conversations
Broadly speaking, here's what those questions and the resulting conversations entail.
01 "Can another customer's data ever touch ours?"
This is often the first question a security engineer asks. It's also the one that most exposes integration platforms that weren't built for the embedded use case. The phrasing varies, but it's usually something like "Describe your multi-tenancy model, explain how customer environments are separated, and tell us what happens when one tenant misbehaves."
A good answer needs to go further than "We use a shared database with a tenant ID column." The reviewer wants to know the blast radius. If one customer sends a malformed payload or triggers a runaway sync, does it degrade performance for anyone else? If a tenant's credentials are somehow compromised, is there any path from that tenant's data to another's? Can you describe where the isolation boundary sits: at the execution level, the network level, or only in application code?
That distinction matters a lot. Isolation enforced only by application logic is a software control, and software has bugs. Isolation enforced by architecture, separate execution environments per customer, network-level segmentation, is a property of the system that doesn't depend on every line of code being correct. Reviewers who've seen a few of these questionnaires know the difference, and they'll ask a follow-up question to find out exactly which one they're getting.
Another related thing that reviewers want to know is how you manage security for your app's UI. Your customers set up their integrations on screens built into your product. Reviewers want to know three things about those screens: how a user gets signed in to them, whether one customer's user could ever see another customer's settings or connections, and whether the screens follow the same user roles as the rest of your product.
02 "Where do our credentials live, and who at your company can see them?"
Credential handling gets its own questions because it's the scenario every security team has a war story about: an OAuth token that ended up somewhere it shouldn't have, often because someone was debugging something and forgot to turn verbose logging off.
The technical half of this question is familiar by now. Stored credentials should be encrypted at rest, decrypted only at runtime, and accessible only to the owning tenant. The platform, not your application code, should manage OAuth authorization, token storage, and refresh. Disconnecting a connection should remove the stored credential and, where the provider supports it, revoke the token at the provider. Externally initiated disconnects will vary. If a vendor can't explain exactly where a token lives at every stage of its lifecycle, that's a strong signal the platform wasn't built with enterprise credential hygiene in mind.
There's a second half to this question: "Who can see it?" As an integration program grows, more people have access. Developers build integrations. Support troubleshoots them. CS configures them. If any of those people can pull up a customer's raw credentials, or edit a production integration without leaving a record, that's a gap a security reviewer will find. Reviewers will also ask whether a support rep or developer can change a customer's production configuration without it being tracked. This is where role-based access control and least privilege stop being internal IT hygiene and become part of your customer-facing answer. A strong answer on credentials sounds like: "There is no standing human access to decrypted credentials; any break-glass access is logged and can be reviewed."
There's a liability question, too, and legal will ask it even if security doesn't: "If a credential leaks, whose fault is it, contractually speaking?" A vendor who owns the entire credential lifecycle, and can show you exactly who inside their company has a technical path to it, has an easier time answering that than one where your integration code passes tokens around and hopes for the best.
03 "Can you show me who did what, and when?"
Every enterprise security review eventually gets to audit logs, and the bar here is higher than many teams expect. "We have logs" is not the same answer as "We have logs a security reviewer, or an incident responder, can use."
It helps to separate two things that often get lumped together. Execution logs tell you what an integration did: whether it ran, which steps executed, what failed, and which customer instance was involved. Audit logs tell you what a person did: who changed a configuration, who deployed a new version, when, and under what authorization. You need both, and a security reviewer will usually ask about them separately.
Beyond that, the questions are consistent:
- Are logs immutable or tamper-evident, with synchronized timestamps, or can someone with database access edit them after the fact?
- Is access to the logs itself logged?
- How long are they retained, and does that meet the buyer's own compliance requirements?
- And can they be streamed or exported into the buyer's own observability tool, so their security team isn't logging into a separate dashboard to reconstruct what happened?
A platform that only produces a report after something has gone wrong puts your customer's security team in a reactive position during an incident. One that streams events in real time lets them see it happen. Reviewers who've been through a real breach tend to ask which one they're getting, because they already know which one they'd rather have.
More logging isn't automatically better logging. If integration logs capture full API payloads, tokens, or personal data, you've created a second place that sensitive data needs to be protected, and a security reviewer will ask about that too.
04 "Can we see your SOC 2 report?"
SOC 2 Type 2 often functions as a gate rather than a differentiator. Most platforms that survive to the procurement stage have it. What separates a smooth review from a slow one is everything that happens in the conversation after you confirm the attestation.
Procurement and legal will typically ask for the audit report, not just the badge, along with the scope of what was audited and management-issued bridge letters covering the gap since the last audit period. They'll ask what else applies to your specific market: HIPAA if you touch PHI in the US, GDPR if you have EU customers or data subjects, CJIS for US criminal justice information, PCI DSS if cardholder data is in scope, and StateRAMP/GovRAMP or FedRAMP for US public-sector buyers.
For HIPAA, the key pieces are a signed BAA plus HIPAA-aligned controls. For CJIS, you'll need the CJIS Security Addendum, fingerprint-based background checks for personnel with access, and approval from the state CJIS Systems Agency.
SOC 2 tells a buyer that a third party evaluated a vendor's controls. It doesn't, by itself, tell them how a specific customer's integration instances are isolated or who can access them. Reviewers increasingly know this. If your integration platform already holds the attestations and agreements your market requires, and can map them to the specific runtime that touches customer data, this section of the review goes quickly. If your platform lacks those attestations and agreements, no amount of custom coding closes that gap before the deal timeline runs out.
05 "Where does our data live, and who else touches it?"
Data residency and sub-processor transparency get their own line of questions, separate from the compliance conversation, and they come up more often than they used to. An EU-based customer, or a US customer with EU users, will ask directly whether their data stays within the EU, or whether a lawful transfer mechanism (Standard Contractual Clauses, EU-US Data Privacy Framework) is in place. A healthcare or public-sector buyer will ask for a complete, current sub-processor list.
The underlying question is about the full lifecycle of a piece of data as it moves through an integration: "Where is it processed, is it persisted anywhere, for how long, does it show up in execution logs, and can it be deleted on request?" This is also where the questions may reach past your own product and into your integration vendor's vendors. If your integration platform runs on infrastructure with its own sub-processors and regions, that entire chain is now part of what your customer's privacy officer is evaluating. Being able to answer with specific details is something reviewers notice immediately.
06 "What happens when something goes wrong, and how fast can you tell us who was affected?"
Every enterprise contract negotiation eventually covers breach notification terms, and you should have an answer to the question: "What's the notification window, what triggers it, and (in a shared-responsibility model) who's on the hook for notifying your customer, you or your integration platform vendor?"
GDPR requires a controller to notify the supervisory authority within 72 hours of becoming aware of the breach; a processor must notify the controller "without undue delay." HIPAA requires a business associate to notify the covered entity without unreasonable delay and no later than 60 days after discovery. Enterprise contracts commonly negotiate 24 to 72 hours. US state breach laws add their own timelines.
There's an operational side to this as well: "If something does go wrong, how quickly can you say which customers were affected?" In a multi-tenant integration program, incidents rarely hit everyone equally. Ten customers might be on an integration version or configuration that nobody else uses. If answering this requires three engineers and an afternoon of database queries, that's the kind of gap a security reviewer will find.
07 What else will the questionnaire include?
In addition to what we've already covered, expect these on nearly every security questionnaire:
- Penetration testing and vulnerability management (cadence, fix SLAs)
- SSO/SAML, SCIM, and MFA for the vendor's own console
- Business continuity and disaster recovery (RTO/RPO)
- Secure development lifecycle
- Whether your customer data is used to train models, and which AI sub-processors touch it.
What parts are yours to answer
A secure integration platform doesn't automatically make every integration you build secure. A shared-responsibility model underlies all the questions above, and knowing where the line is saves you from over-claiming or under-claiming during a review.
The platform should own the security for its infrastructure: credential storage, execution isolation, authentication, encryption, and platform-level auditability. Your team owns what you build on top of it. If an integration requests far more OAuth scope than it needs, the platform doesn't make that decision for you. If custom code logs a full API response that contains sensitive data, isolated execution doesn't undo it. The third-party applications you connect also have their responsibility: they control their APIs, their auth flows, and much of what your customer is granting access to.
Being able to differentiate all this in front of a security reviewer signals maturity. It tells them you understand your own architecture well enough to know what you're vouching for and what you're not.
Build the answers ahead of time
Every question above becomes your team's problem to answer, even when your integration platform provides the control. Enterprise buyers don't distinguish between your product and the vendors underneath it. They see one risk surface, and they expect a corresponding set of answers.
You probably already have the raw material for this sitting in previously-completed security questionnaires. Pull out the questions that keep coming up, the ones that have slowed down a deal before, and turn them into a standing answer packet. Create a trust center or security page with certifications and audit reports available on request, a pre-filled response to common questionnaire formats, a DPA template that's ready for redlines, and a current sub-processor list.
Some of those answers are yours to build. But, a meaningful amount of it (tenant isolation, credential lifecycle, certifications, and audit logs) is inherited from your integration platform. Choosing a platform that already has these answers for you greatly reduces the number of questions your team has to answer live, under deal pressure.
Boring security reviews are the goal
It's tempting to think of enterprise security as a set of features an integration solution needs to have. But, there's a better way to look at it. The goal is for your next security review to be uneventful. The prospect asks how tenants are isolated, and you have an answer. They ask who can see a credential, and you have an answer. They ask what happened at 1:17 AM on a Tuesday, and you have an answer. Nobody fires up an emergency Slack thread or grabs an engineer to figure out how a token is stored.
That's a much better test of enterprise readiness than whether a vendor tells you "Yes, we support enterprise security." Everyone says yes. That's not so much an answer as the start of the question.
If you're evaluating how your current integration setup would hold up under this kind of review, Prismatic's security policy and Trust Center are built to be handed directly to a security reviewer, with audit reports available upon request.
And if you want a closer look at how the platform works, we've covered that too.
Common questions
No. A SOC 2 Type 2 report is usually the minimum, not the whole answer. Buyers also ask how tenants are isolated, how credentials are stored and who can reach them, and which other requirements apply to their market, such as HIPAA, GDPR, or CJIS.
