============================================================================== FRONTIVA: SECURITY QUESTIONNAIRE, ANSWERED IN ADVANCE ============================================================================== Last updated: September 26, 2026 Current version: https://frontivatech.com/trust Questions this does not answer: security@frontivatech.com Every answer below was checked against the running system rather than against another document. Each carries a reference you can quote back to us. Where the answer is no, it says no in the first clause: 18 of the 57 answers are no and 9 are in part. The certifications section is almost entirely no, and it is first rather than last. Status words: YES means in place today. IN PART means some of it is true and the answer says which part is not. NO means no. This file is generated from the same answers as the web page, so it cannot say something the site does not. ------------------------------------------------------------------------------ CERTIFICATIONS AND AUDITS ------------------------------------------------------------------------------ First, because it is what a reviewer checks first, and a vendor who buries it has told you something already. CERT-1 [NO] Do you hold a SOC 2 report? No, and none is in progress. We are a new company with a small team, and a SOC 2 report costs more than it would tell you about us today. What we offer instead is this document, a data processing addendum, and a named person who will answer a question you cannot find here. CERT-2 [NO] Do you hold ISO 27001 or any equivalent certification? No. CERT-3 [NO] Will you sign a Business Associate Agreement under HIPAA? Not today. If you are a covered entity, read this answer carefully rather than filing it: our dental and med spa templates ask a patient for insurance details and current medications, so the product is capable of collecting protected health information, and without a signed BAA the obligation to have one sits on your practice rather than on us. Do not put PHI into Frontiva until we can sign one. Ask us where that stands before you buy, because it is the single question most likely to decide whether we are a fit. CERT-4 [YES] How is cardholder data handled, and what is your PCI DSS position? Card details never reach Frontiva. Payment pages are hosted by Stripe and the card is entered on their pages, which keeps us to the simplest merchant questionnaire rather than in scope for storing card data. Billing is not switched on yet, so today no card is taken at all. CERT-5 [NO] Have you had an external penetration test? No. The application has never been assessed by anybody outside the team. We would rather tell you that than describe our own automated checks as though they were an assessment. CERT-6 [NO] Do you carry cyber or professional liability insurance? Not yet. If your procurement requires a certificate, tell us and we will tell you honestly whether we have it by the time you need it. CERT-7 [NO] Are you set up for customers or data subjects in the EU or the UK? No. Frontiva is built for the United States: the servers are in the US, the messaging rules it enforces are US ones, and the legal basis it relies on for marketing email is the US opt-out regime. An EU or UK customer would need decisions we have not made and a review we have not had. ------------------------------------------------------------------------------ WHERE THE DATA LIVES, AND WHAT IT IS ------------------------------------------------------------------------------ The questions that decide whether the rest of the form matters to you. DATA-1 [YES] Where is customer data hosted, and in which country? In the United States, on one virtual server from a single hosting provider, with the database on that same machine. There is no second region and no second copy of the service. DATA-2 [YES] Is the platform multi-tenant, and how is one customer kept from another? Multi-tenant, one database, and the isolation is the property this product is most careful about. See the tenant isolation section below, which is where the mechanism and its automated check are described rather than asserted. DATA-3 [YES] What categories of data does the service hold? Contact details for the people who message a business, the content of those conversations across every channel, appointments, leads and tasks, the business's own knowledge base, its staff accounts and its audit log. Because customers write what they like into a message, health information can appear in a conversation at a healthcare practice even where no form asked for it, which is what makes CERT-3 the important answer above. DATA-4 [NO] Can you commit contractually to data residency? No further than this: the provider's servers are in the United States and we have no mechanism that moves data elsewhere. We do not offer a residency guarantee, a choice of region, or a commitment about where a future subprocessor might sit. DATA-5 [NO] Is customer data used to train AI models? No. Message content goes to the AI provider to generate one reply and to the messaging provider to be delivered, and nothing is used to train anybody's model, ours or a provider's. This is in the data processing addendum, not only here. DATA-6 [NO] Do you sell, rent or share customer data? No. The subprocessor list is the complete list of who sees it and why. ------------------------------------------------------------------------------ TENANT ISOLATION ------------------------------------------------------------------------------ The one question a multi-tenant vendor should be able to answer with a mechanism rather than an assurance. ISO-1 [YES] How is data segregated between tenants? Every table that belongs to a business is read and written through one shared code path that filters by that business automatically. Application code does not write its own queries against those tables, so it cannot forget the filter. ISO-2 [YES] Is that enforced, or is it a convention developers follow? Enforced. An automated check runs on every change, walks 66 tenant-owned tables, and fails the build if any code queries one outside that path. It has caught real mistakes, including one made while building the feature this pack was written alongside. ISO-3 [NO] Can an authenticated user of one account reach another account's data? Not through any route we have found, and it is checked rather than assumed: a second automated test walks every endpoint in the product and fails the build if one of them serves data without establishing who is asking and which business they belong to. A loaded record is also re-checked against the caller's business after it is fetched, so a broken filter fails loudly instead of leaking. ------------------------------------------------------------------------------ ACCESS CONTROL AND AUTHENTICATION ------------------------------------------------------------------------------ Who can sign in, what they can reach, and what happens to a session. AC-1 [YES] What access control model does the application use? Five roles (Owner, Admin, Manager, Agent, Viewer) against a defined permission catalogue, and members can be scoped to particular locations so a receptionist at one site sees only that site. AC-2 [YES] Is multi-factor authentication available for customer users? Yes, by authenticator app, and an owner can require it for everybody in the account. It is not on by default. AC-3 [NO] Do you support SAML or single sign-on? No. Sign-in is email and password, with the optional second factor above. AC-4 [IN PART] How are passwords stored, and what is the policy? Hashed with bcrypt, never stored or logged in any recoverable form, and never returned by any endpoint. The policy is a minimum of eight characters and nothing else: no composition rules, no forced rotation, no breach-list check. That is a deliberate choice for the first two and a gap for the third. AC-5 [YES] How are sessions handled? An access token lasts fifteen minutes. The refresh token that renews it is rotated on every use and the old one revoked, so a stolen refresh token stops working as soon as the real session uses it again, and it is stored as a hash rather than in readable form. A user can end every session on every device from their own profile, including the one they are using. AC-6 [IN PART] Can your staff see or enter a customer account? Account-level facts, yes: which businesses exist and how much they are using. Entering an account is a separate, deliberate act called a support session. It needs a written reason, expires after at most sixty minutes, uses the permissions of one member of that customer's team rather than special powers, and can be ended by either side at any time. Its start, its end and every change made during it appear in the customer's own audit log with the staff member named. AC-7 [YES] Is MFA required for your own staff? Required, not optional: every staff sign-in takes a password and an authenticator code, sensitive actions ask for a fresh code, sessions end after thirty minutes of inactivity, and repeated wrong attempts lock the account. Staff accounts are a separate system from customer logins, with a different token audience, so a customer credential cannot reach the admin at all and a staff credential cannot open a customer account directly. ------------------------------------------------------------------------------ ENCRYPTION AND KEY MANAGEMENT ------------------------------------------------------------------------------ Including the part most packs leave vague. ENC-1 [YES] Is data encrypted in transit? Yes. TLS 1.2 and 1.3 only, older versions refused, plain http redirected, and HSTS set to two years so a browser that has visited once will not try http again. Certificates are issued and renewed automatically, and their expiry is one of the things the monitoring checks. ENC-2 [IN PART] Is data encrypted at rest? In part, and the distinction matters. Every stored provider credential (your messaging tokens, mailbox passwords, API keys) is encrypted with authenticated symmetric encryption, so a modified value is rejected rather than decrypted into something else. Database backups are encrypted before they leave the machine. The database volume itself is not disk-encrypted: an attacker with the physical disk or root on the box would read the message content, and the credentials would still be ciphertext. We would rather write that sentence than let a checkbox imply otherwise. ENC-3 [IN PART] How are encryption keys managed? One key, held in the server's environment file, with two offline copies kept away from the machine. There is no key management service, no hardware module, and no automated rotation. The reason the copies are offline and separate is that a key stored beside the database it decrypts is not a backup of anything. ------------------------------------------------------------------------------ APPLICATION AND DEVELOPMENT SECURITY ------------------------------------------------------------------------------ What has to pass before a change can reach you. APP-1 [YES] What automated checks run before a release? Every push runs: 2,115 backend tests, a linter, a type check, the tenant-isolation check described above, the endpoint authentication walk, dependency vulnerability audits on both the Python and the JavaScript trees, static analysis of our own code, a scan of the whole git history for committed secrets, a database migration drift check, a check that the shipped image contains no development tooling, accessibility checks, performance budgets, and visual regression on the design system. What that does not do is physically block a release: deploying is one command run by a person, and the command checks that the code is committed and pushed rather than asking whether the build was green. In practice it is checked by hand first. Making it mechanical is on our list and is not done. APP-2 [NO] Is code reviewed by a second person before release? No. The team is one engineer today, so the gates in APP-1 do the work a reviewer would, and they are deliberately strict because of it. If a second pair of eyes is a requirement for you, say so and we will not pretend otherwise. APP-3 [YES] How do you verify that inbound provider traffic is genuine? Signatures on inbound webhooks are verified against the provider's own signing method before the payload is processed, and a delivery that fails verification is refused rather than logged and accepted. Provider deliveries are also recorded with the provider's own message id, which makes a replayed delivery a duplicate rather than a second action. APP-4 [YES] Are public endpoints rate limited? Yes. The public forms, the booking page, the chat widget and sign-up are limited by address, sign-up at five attempts an hour, and the widget separates polling from message sending so a chatty page cannot exhaust a visitor's ability to write to you. APP-5 [IN PART] How are dependencies managed? Pinned to exact versions, so nothing changes underneath us without somebody deciding, and audited on every push, with the JavaScript audit failing the build on anything rated high or above. The part that is manual is the update: a pin has to be moved by hand, and the audit is what tells us one needs moving. There is no automated update bot, so the honest answer on patch speed is that it depends on us noticing a failing audit, which happens on every push. ------------------------------------------------------------------------------ AVAILABILITY, BACKUP AND CONTINUITY ------------------------------------------------------------------------------ The weakest part of this pack, described accurately, because a buyer who discovers it later will be right to be angry. AVAIL-1 [NO] What is the architecture, and is it highly available? Not highly available. One virtual server runs the application, the worker, the database and the cache. There is no load balancer, no standby, no second region, and a failure of that machine is an outage of the whole service. AVAIL-2 [NO] Do you offer an uptime commitment or an SLA? No, and we do not publish an uptime percentage either, because we have not been running long enough to have measured one honestly. There is a public status page. AVAIL-3 [YES] How is the service monitored? Every five minutes, automatically: the three public addresses, the API's readiness against the database, all six containers, disk, memory, certificate expiry and whether last night's backup actually happened. Failures send mail to a monitored address. The alerting was proved by breaking it deliberately rather than assumed to work. AVAIL-4 [IN PART] How are backups taken, and have they been restored? The database is dumped nightly and fourteen days are kept, and a restore has been performed into a scratch database rather than merely scheduled: a backup nobody has restored is a hypothesis. The gap is where those copies live. Offsite copies are built and tested and switched off, waiting on one storage bucket, so today the backups sit on the same machine as the database. Losing that machine would lose them with it. This is the most significant weakness on this page, we know exactly what fixes it, and you should ask whether it is fixed before you sign anything. AVAIL-5 [IN PART] What are your RPO and RTO? Realistically: up to twenty-four hours of data at risk, since backups are nightly, and recovery is best effort by one person from a written runbook rather than a tested failover with a measured time. We have not rehearsed a full machine loss, which follows from AVAIL-4. ------------------------------------------------------------------------------ LOGGING, AUDIT AND MONITORING OF ACCESS ------------------------------------------------------------------------------ What is recorded, and what a customer can read back. LOG-1 [YES] Is there an audit trail a customer can read? Yes. Every write by a person or by the AI is recorded in that business's own audit log, readable and exportable by the business, including everything done during a support session and who did it. An audit trail only the vendor can read is not one you can rely on. LOG-2 [YES] Are your own staff actions logged, and can they be altered? Logged in a separate staff log that the application cannot edit or delete, where each entry is linked to the one before it, so a change made behind its back is detectable rather than invisible. LOG-3 [YES] What is in your server logs? Request method, path, status, duration and a request id, for tracing a fault. Message content is not written to the application log. LOG-4 [YES] How long are IP addresses kept? Full addresses on enquiries and sign-ins are shortened to their network after ninety days, on both the customer side and our own staff sessions. ------------------------------------------------------------------------------ INCIDENT RESPONSE AND REPORTING A PROBLEM ------------------------------------------------------------------------------ What happens when something goes wrong, and how to tell us. IR-1 [IN PART] Do you have an incident response process? There is a written incident runbook covering the situations that actually happen (a service down, the database, the worker, disk, memory, certificates, a bad migration, events that stopped being delivered), written to be usable at three in the morning. What there is not: a formal on-call rota, a retained response firm, or a second person to escalate to. IR-2 [YES] Will you notify us of a breach, and how quickly? Yes, without undue delay, with what we know at the time rather than waiting until the picture is complete. The commitment is in the data processing addendum, not only in this document. IR-3 [YES] How do we report a vulnerability? Email security@frontivatech.com. There is no bug bounty and we will not pretend there is; real reports get answered and fixed, and we will tell you when the fix shipped. IR-4 [YES] Do you notify customers before adding a subprocessor? Before adding one that handles the content of your customers' messages, yes, so you have the chance to object. ------------------------------------------------------------------------------ THE AI ------------------------------------------------------------------------------ Increasingly the longest section of a buyer's form, and the one where vague answers do the most damage. AI-1 [YES] Which AI provider do you use, and what is sent to it? Anthropic, in the United States. What is sent is the conversation the reply is for, plus the facts and answers the business itself has approved. Nothing is used to train a model. AI-2 [NO] Can the AI say something the business has not approved? It answers from approved facts and question-and-answer pairs rather than from general knowledge, and a question it cannot answer from them is handed to a person, with the customer told. Deterministic checks run before any answer is attempted: prompt-injection detection, and a refusal to engage with sensitive subjects such as medical advice or a price it has not been given. AI-3 [YES] Does a human review AI replies? By default every reply waits for a person to approve it, and the draft shows which of the business's own answers it came from and how well the question matched, so approving is a decision rather than a guess. Letting the agent answer on its own is a separate switch that will not turn on until the agent has passed a readiness suite. AI-4 [YES] How much of a customer's history can the AI read? Whatever the business chooses: this message only, this conversation, or the customer's earlier conversations as well. The widest setting is opt-in and bounded by an age and a count, and the narrowest is the default for a new agent. AI-5 [NO] Does the AI reply to email? No. Email arrives in the shared inbox and waits for a person. That is a deliberate limit rather than a missing feature. ------------------------------------------------------------------------------ PEOPLE AND INTERNAL ACCESS ------------------------------------------------------------------------------ Where being a small company is a fact rather than a selling point. PPL-1 [NO] How many people can reach production, and is there separation of duties? There is no separation of duties. The company is small and the owner has server access, which means the person who writes the code can also reach the database. The compensating controls are the ones above: staff MFA, the recorded support-session path for entering a customer account, and a staff audit log the application cannot rewrite. They are compensating controls, not a substitute, and you should weigh them as such. PPL-2 [NO] Do you run background checks and security training for staff? No formal programme for either today. PPL-3 [YES] How is server access controlled? By SSH key. Password sign-in over SSH is refused, so a guessed or reused password reaches nothing. Deployments authenticate as a separate unprivileged account, not as the administrator: a release builds, ships, migrates and rolls the stack without root, and it writes only the three files a release actually changes rather than the whole directory. The scripts our scheduled jobs run as root live in a separate directory that the deployment account cannot write at all, so a compromise of the deployment is not a compromise of the machine. Owning those files was not enough on its own: whoever owns a directory can replace what is in it, so they were moved out of the one a release writes. This answer said "in part" until 2026-09-27, because the connection was still the administrator's; we found that by checking the server rather than by reading our own notes, which claimed otherwise. PPL-4 [YES] What happens when a staff member leaves? Their staff account is deactivated, which ends their sessions, and any support session they had open ends with it. Sessions can also be ended remotely at any time without waiting for one to expire. ------------------------------------------------------------------------------ RETENTION, EXPORT AND DELETION ------------------------------------------------------------------------------ What we keep, what you can take, and what happens when you leave. RET-1 [YES] How long is customer data kept? Conversations are kept until the business decides otherwise. Choosing a retention period is the business's own setting, it is off unless turned on, and the screen shows exactly what a policy would remove before it is saved. Our own operational records have fixed short lives whatever the business chooses: refresh tokens thirty days, password reset requests seven, the outbound mail queue fourteen, webhook events ninety and their delivery attempts thirty. RET-2 [YES] Can we export our data, and in what form? From the product, at any time, without asking us: a zip of spreadsheets holding contacts and how to reach them, every conversation and message, appointments, leads, tasks, notes, the knowledge base, the team and the audit log. Channel credentials are deliberately not in it. RET-3 [YES] What happens to our data if we close the account? The owner closes it from the same screen, and everything the business holds is permanently deleted thirty days later. Nothing changes during those thirty days and the deletion can be called off at any point before the date: the window exists so you can change your mind and take a copy, not to wind the service down while you decide. RET-4 [IN PART] Are deletions propagated to your subprocessors? For anything we hold, yes. Messages already delivered by a messaging provider, or mail sitting in the business's own mailbox, are in systems the business or the provider controls and are subject to their retention rather than ours. Attachments are the clearest case: we record a file's name, type and size, and the file itself stays in your mailbox. ------------------------------------------------------------------------------ SUBPROCESSORS ------------------------------------------------------------------------------ Everyone who processes data on our behalf. The first five are named in the data processing addendum; the last handles visitors to our website rather than anything from the product. Message content says whether they can see what your customers write. Hostinger (Lithuania, servers in the United States) hosting, the database, and our own email. Sees message content: yes Named in the DPA: yes Twilio (United States) sending and receiving text messages and calls. Sees message content: yes Named in the DPA: yes Anthropic (United States) the AI that drafts and sends replies. Sees message content: yes Named in the DPA: yes Meta Platforms (United States) Instagram, Messenger and WhatsApp messaging, for customers who connect them. Sees message content: yes Named in the DPA: yes Stripe (United States) card payments and invoices, once billing is switched on. Card details are entered on Stripe's own pages and never reach Frontiva. Sees message content: no Named in the DPA: yes Google (United States) website analytics on frontivatech.com, only for visitors who allow it. It sees no customer data from the product. Sees message content: no Named in the DPA: no ------------------------------------------------------------------------------ WHAT THIS IS NOT ------------------------------------------------------------------------------ It is not an audit. Nobody outside the team has assessed any of it (CERT-5). If you need assurance from a third party, we do not have it today, and saying so is the honest version of this document.