Vibe code audit
Plaid asks for a security questionnaire before a paid app can use certain bank APIs, and payment providers and enterprise buyers send their own before they let you in. We audit your app. For fintech, health and HR products the audit comes with a draft of the answers based on what the code actually does, so every answer you send matches the software.
A vendor security questionnaire is a list of questions a bank, payment provider or enterprise customer sends before it connects to your product or buys it. It asks how you control access, protect and delete data, handle incidents and manage the suppliers that receive your data. Your answers become commitments you can be held to.
Founders who built with Lovable, Bolt, Cursor or Replit often answer from memory of what they asked the AI tool to build. The questionnaire asks what the code does. Those two answers can differ, and the reviewer on the other side may test them.
Plaid describes it as a questionnaire about "your company's risk and security practices". Plaid does not publish the questions; the form is in the Plaid Dashboard. US and Canadian apps on a paid plan must complete it before they can use certain bank APIs, Chase among them, and the Plaid Risk team reviews the answers.
Who completes it: Plaid's OAuth guide and its help article on OAuth registration list the questionnaire as a requirement for US and Canadian integrations that want OAuth institutions. Apps on the Trial plan do not need it until they move to a paid plan. Reseller partners must submit one before they can create end customers.
When it unlocks: Plaid's help article on upgrading from the Trial plan says the questionnaire step stays greyed out until your Production application is approved. The OAuth guide says the review may take some time and recommends submitting as early as possible in the integration.
Who reviews it: the Plaid Risk team reviews the answers and contacts you if it has follow-up questions. If the rest of your integration is ready and the questionnaire is still not approved, Plaid tells you to contact your account manager or support.
The closest public statement of what Plaid expects is the security section of its Developer Policy, summarised in the next section.
Read Plaid's OAuth guidePlaid's Developer Policy sets minimum security controls for every developer that handles end user data from Plaid. These are policy requirements, separate from the questionnaire's own questions, and they are the closest public statement of what Plaid expects. For each one we look for evidence in your code and configuration during the audit.
| What Plaid's Developer Policy requires | What we look for in the audit |
|---|---|
| Administrative, technical and physical safeguards for end user data | Where data from Plaid is stored, which services and tables hold it, and who can change those stores. |
| Modern, industry standard encryption when end user data is stored or sent | TLS on every connection that carries the data, encryption at rest in the database and file storage, no plain copies in logs. |
| Access only for authorised people with a business need | Role and row-level checks tested as real users, admin and service keys kept on the server, team access to production. |
| Monitoring systems for unauthorised access | Whether failed sign-ins, admin actions and unusual data reads raise an alert that someone receives. |
| Patching vulnerabilities in a timely way | Dependency audit results, packages with known vulnerabilities, and whether updates are automated. |
| Logging and reviewing events that suggest unauthorised access | What the app and database log, how long logs are kept, and whether anyone reviews them. |
| Planning for and responding to security incidents | A written incident runbook, named owners and a tested restore of the database and stored files. |
| Following the rules for your type of data, such as the GLBA Safeguards Rule | Retention and deletion of financial data, and whether your written policies match what the code does. |
| Plaid client ID, API secret and Dashboard logins kept confidential and encrypted | The Plaid secret kept out of client code and git history, stored server side, rotated after any exposure. |
| Prompt notice to Plaid at security@plaid.com after a breach | Whether your incident runbook names Plaid as a party to notify, with the address. |
Paraphrased from the Security section of Plaid's Developer Policy (effective 19 April 2026), read on 13 November 2026. The Developer Policy is a separate document from the questionnaire. GLBA is the US Gramm-Leach-Bliley Act; TLS is the encryption used for data in transit.
Most questionnaires cover the same ground: access control, sign-in and multi-factor authentication, keys and secrets, data retention and deletion, the third parties that receive data, consent, incident response and how changes reach production. For each topic we check the code and record either evidence for your answer or the gap to close first.
| Questionnaire topic | What we check in the code | A gap we found in an audit |
|---|---|---|
| Access control | Who can read and change each record, tested as real user roles. | Private records readable by another member of the same account. |
| Sign-in and MFA | Session handling, multi-factor sign-in and production auth settings. | MFA built in code, production auth settings never verified. |
| Keys and secrets | Keys kept out of client code and git history, rotated after any exposure. | Secrets exposed in git history and not yet rotated. |
| Retention and deletion | Retention periods, account deletion across every store and provider, data export. | No retention schedule for AI chat logs. Account deletion never exercised. |
| Third parties | Every service the code sends user data to, compared with your privacy policy. | The processor list did not match the integrations in the code. |
| Consent | When analytics and AI features start, compared with what the policy promises. | Analytics started before the consent choice the policy promised. |
| Incidents and recovery | Alerts, runbooks and evidence that a restore of the database and stored files has been tested. | No runbooks, no alerting shown to fire, no rehearsed restore. |
| Change management | Release gate with tests, type check, dependency and secret scans, branch protection. | No enforced release gate. Errors could reach production. |
Gaps come from our anonymised sample report and an anonymised production readiness audit of a Next.js and Supabase platform. MFA means multi-factor authentication: a second proof of identity on top of the password.
In one pre-launch audit, the terms, privacy and cookie policies promised things the software did not do. Analytics started before any consent choice, the processor list did not match the integrations in the code, and the entity details were placeholders. A questionnaire answered from those policies would have described a different product.
The list of processors did not match the integrations in the code.
Every questionnaire asks which third parties receive user data. The policy gave one answer and the code gave another. We list every integration the code calls, so the answer you send is accurate. From our anonymised sample report.
Sample report based on a real audit. Client details and figures changed.
Get the sample report1 blocking, 12 high and 2 lower findings in one audit.
Neither an EU nor a UK launch could be cleared on the evidence. Most of the work was engineering: consent enforcement, deletion, payment correctness and incident readiness. The fix for consent is default-deny with tested refuse and withdraw paths.
Secret exposure was documented and the keys were not yet rotated.
In a Next.js and Supabase business platform, the team had recorded that secrets had been exposed in git history. Rotation and a history scrub were still open, so the honest answer on key management needed that work done first.
We audit the code first and draft the answers from what we found. Each answer points to evidence in the code or to a finding with its fix. For fintech, health and HR products the audit comes with the provider questionnaire draft and a SOC 2 and GDPR control matrix. You review the draft and send it.
Forward the questionnaire you received, or tell us which bank, payment or data provider is about to ask for one.
A senior engineer reviews the code across 8 areas with read-only access.
For fintech, health and HR products, or a bank or payment provider about to ask: answers pre-filled from the findings, with every gap marked and the fix for it.
We walk through the gaps worth closing before you send the questionnaire.
The vibe code audit starts from $199 at a fixed price. Tell us a bank, payment or data provider is about to send a questionnaire, and the audit then includes the provider questionnaire draft. If the audit finds gaps you need to close first, you get a fixed-price quote for that work.
Everything this page says about the Plaid security questionnaire comes from Plaid's own public documentation, help center and Developer Policy, linked below. We read each page on 13 November 2026. Plaid updates these pages, so check the current version and your Plaid Dashboard before you rely on a detail.
Common starting points are the Vendor Security Alliance questionnaire, the Shared Assessments SIG and the CAIQ from the Cloud Security Alliance. Most banks and enterprises send their own version. A template helps you prepare, but each answer still has to match what your code and your team actually do.
Plaid says the questionnaire covers how your company handles risk and security, and Plaid does not publish the questions; the form is in the Plaid Dashboard. Its Developer Policy lists the controls Plaid expects: safeguards and encryption for user data, need-based access, monitoring, patching, logging, incident response, legal compliance and breach notice. We check each in your code.
It applies to US and Canadian companies on a paid Plaid plan that want OAuth institutions and certain bank APIs, including Chase in Production. It is part of OAuth registration in the Plaid Dashboard. Apps on the Trial plan skip it until they upgrade to a paid plan, and reseller partners must submit one before creating end customers.
The questionnaire step in the Plaid Dashboard stays greyed out until Plaid approves your Production application. Once it unlocks, Plaid recommends submitting as early as possible in your integration, because its review may take some time. The Plaid Risk team reviews the answers and contacts you with any follow-up questions.
It adds questions about your AI features: which model providers receive user data, how long prompts and chat logs are kept, whether users can opt out, and what the AI can change on its own. In one audit, AI consent was skipped on some paths and chat logs had no retention schedule.
Book a 30-minute call. Tell us who sent it and what the app does, and we will tell you what the audit covers.
Prefer to talk?
