Data Processing Agreement

This Data Processing Agreement is part of our Terms of Service. When you subscribe, you accept both. There is nothing separate to sign: this page is the agreement, and the date at the top is the version in force.

The words controller, processor, personal data, personal data breach, special categories and supervisory authority carry the meanings given to them in the GDPR, and the meanings given by the UK GDPR, the Swiss Federal Act on Data Protection or the California Consumer Privacy Act as amended where one of those laws applies to you instead. A subprocessor is anyone we engage to process your personal data on our behalf.

Where this document and the Terms of Service disagree about personal data, this document wins; on everything else — pricing, approvals, the liability between the two of us — the Terms win. Where this document and the Standard Contractual Clauses disagree, the Clauses win. Where this document and our Privacy Policy describe the same mechanism, they are meant to say the same thing; if they ever do not, tell us and we will fix the code or the text, in that order.

Nothing in this agreement or in the Terms of Service limits our liability to a data subject under the Standard Contractual Clauses or under data protection law, and nothing limits a liability that cannot lawfully be limited.

This agreement starts when you start using the service and runs for as long as we hold personal data for you. Deleting your workspace ends the processing; what survives deletion is listed in the section on deletion and return, and the obligations about confidentiality and the limits on what we may do with your data outlive the agreement.

We may update this document. The current version is always here, with its date. We will not reduce the protections in it without publishing the change on this page at least thirty days before it takes effect, and you may end your subscription without penalty before then. Those thirty days are a promise made by us as people, not a feature of the software: we have no automated notification system, and we will not tell you by email, because the product sends no email at all today.

You are the controller of the personal data you bring into the service — your brief, your customers' words if you paste them, the analytics of your own site, the text of the pages you ask us to read. We are your processor for that data: we act on your instructions and for no purpose of our own.

Your instructions are the actions you take in the product: filling in the brief, asking us to read a website, writing to the chief manager, starting a piece, approving a piece for publishing, approving a change to the search title and description of a page we already published for you, connecting a channel. We do not process your data for anything else — no training of our own models, no resale, no enrichment for other customers.

This agreement and the actions you take in the product together are your complete and final documented instructions to us. Processing your data in the United States, and passing it to the subprocessors named in Annex III, are part of those instructions. If a law we are subject to requires us to process your data in some other way, we will tell you what that law requires before we do it, unless the law forbids us from telling you on important grounds of public interest.

If, in our opinion, an instruction of yours infringes the GDPR or other data protection law, we will tell you immediately and we will not carry it out until you confirm it or change it.

For your own account we are the controller, not your processor: your sign-in identity and email, your billing record, and the usage records that show what your plan has consumed. The Privacy Policy covers those, and the Clauses cover them in Module One as described below.

If someone subscribes to our newsletter from the footer of our website, that address is ours as controller too. It has nothing to do with your workspace, and the processor part of this agreement does not cover it.

When you ask us to read a website, you instruct us to open that address, and we read it only on that instruction and only to draft your profile. We choose which of its public pages to open and we do not verify who owns the address. You are responsible for the lawfulness of asking us to read it, and for the personal data those pages happen to contain.

Subject matter: running the service you subscribed to. Nature of the processing: storing your business brief and the content produced from it, sending parts of it to the AI models that write and check that content, reading the public pages of a website when you ask, reading the analytics accounts you connect, storing files, and publishing an approved piece to a channel you connected.

Purpose: producing marketing content for your business and showing you evidence that it was published. The service does not build profiles of individuals, does not score them, does not target them, and makes no automated decision that produces legal or similarly significant effects on anyone.

Duration: for as long as your workspace exists, and after your subscription ends for no longer than the period set out in the section on deletion and return. Nothing in the product deletes itself on a schedule. There is no retention timer, no log rotation and no automatic expiry — data stays until you delete it or we delete it by hand. We would rather tell you that than invent a retention period we do not enforce.

We do not inspect the content of anything you type. Three places are plain free text with no shape at all: the field about what your customers say in your brief, your messages to the chief manager, and the topic you can type when you start a piece. The shorter brief fields — company, niche, city, products, competitors — do reject line breaks and links, but that is a guard against text that tries to give the model orders, not a check for personal data: a person's name fits any of them.

Everything you type is stored, and all of it is sent to the AI model with the rest of your brief. We do not detect names, phone numbers, addresses or anything else in any of it. If you paste a real customer's words with their name attached, that name is now being processed.

The same is true of a piece you edit before approving it: you can write anything into the body, and we publish what you approved. There is no filter between your keyboard and the channel other than your own reading.

Please do not put special categories of personal data into those fields — health, biometrics, religion, ethnicity, politics, sex life or trade-union membership — and do not put children's data into them. The service is sold to businesses and is not built for any of that. We have no control that detects it, so this is a rule you keep, not one we enforce.

When you ask us to read a website, we open at most five public pages and send at most 8,000 characters of each to the model that drafts your profile. Those 8,000 characters are not the top of the page: for every page we assemble its title, its meta description, up to 2,000 characters of its JSON-LD markup and then its visible prose with the navigation, header and footer removed, and we cut the result at 8,000. We aim at the pages that describe a business — about, services, products, pricing, contact. That means the text we send can contain the names, job titles, phone numbers and email addresses printed on those pages.

Here is exactly what protects that data and what does not. We instruct the model not to extract people: no names, no job titles tied to a person, no personal phone numbers or email addresses, in any field. The structured business markup on the page — its JSON-LD block — is the first thing we send, ahead of the prose, and on a small-business site that block is usually where a phone number, a postal address, a founder's name and links to social profiles are declared, so all of those reach the model; a phone number printed in the visible text reaches it too. The pages themselves are not saved anywhere; they exist for the length of that one request, and what we keep is the address you asked for, recorded as one line in the log of runs. What we do not have is a filter that strips people out of the page text before the model sees it, and we do not check the model's output for personal data; our server only checks that a quote it shows you really appears on the page you named. Earlier versions of this document said that rule was enforced in our extraction code, and that the markup never reached the model. Neither was true, and we have corrected the statements rather than leave them standing.

Our quality gates read the title and body of a piece and, for an article, the five lines of your brief that we send with it as the facts to check against: your city, your products, your competitors, the free-text field about what your customers say, and your website address. Both reviewers receive those five lines, whether or not their own rubric asks for them. The gates look at the claims the piece makes — medical, legal, financial, unverified. They are not privacy controls and they will not notice personal data.

We use subprocessors to run the service. Annex III lists every one of them, what it does, and what it receives. Each of them receives only what its function requires.

You give us general authorisation to use them. If we add a new one, we will publish the updated list on this page at least thirty days before it starts processing your data, and those thirty days are the period referred to in Clause 9(a) of the Standard Contractual Clauses. We will not send you an email about it, because the product sends no email today and we would rather not promise a message we cannot send. Check this page, or ask us and we will tell you.

You may object to a new subprocessor. Be aware of what objecting can and cannot achieve: the database, the hosting, the sign-in provider, the background-job engine and the AI models are not switchable for one customer — without them there is no service. If you object to one of those, the honest remedy is to stop using the service and ask us to delete your workspace, and, notwithstanding the Terms of Service, we will refund the unused part of the period you have paid for.

Each subprocessor is bound by data protection terms that impose on it obligations equivalent to the ones we owe you under this agreement, including the Standard Contractual Clauses where it processes personal data outside your region. We remain fully liable to you for the performance of every subprocessor's data protection obligations, exactly as if we were doing that work ourselves.

We have not audited our subprocessors ourselves and we will not pretend otherwise. What we rely on are their published data processing terms, which you can read for yourself, and on request we will give you a copy of our agreement with any of them with the commercial terms removed.

As we read those terms, none of the AI providers we use may train its models on your content. That is a term we rely on, not something we have verified beyond reading it.

We use one error-tracking vendor, Sentry, listed in Annex III. It receives the text of error messages and the code path that failed. We have turned off the settings that would send it more than that: it does not receive your account details, it does not record what you do on screen, and it does not collect the values of variables from the code that failed — the place where your article text and your channel credentials would otherwise appear.

Your data is processed in the United States. Our database runs in AWS us-east-1 — we read that setting from our database provider on 14 August 2026, and it is a fact we can re-check, not an intention. Our hosting account and our file storage are also US-based; the exact location of stored files is chosen by our storage provider, not by us. There is no EU or UK data residency option, and we will not offer one until it exists.

If you are in the European Economic Area, the United Kingdom or Switzerland, that is a transfer of personal data outside your region. To cover it, the European Commission's Standard Contractual Clauses of 4 June 2021 are incorporated into this agreement by reference, using Module Two, controller to processor, for the data we process for you. You are the data exporter; we are the data importer. Annex I of this document fills in Annex I of those Clauses, Annex II fills in Annex II, and Annex III is the subprocessor list they require. For Clause 9 we use Option 2, general written authorisation, with the thirty days described above.

For the personal data of which we are the controller — your sign-in identity, your email address, your billing record and your usage records — the same Clauses are incorporated in Module One, controller to controller, with the same Annexes, the same governing law and the same forum.

For Clause 17 the governing law is the law of Ireland. For Clause 18 the forum is the courts of Ireland, which does not affect the right of a data subject to bring proceedings in the Member State in which he or she has his or her habitual residence. Clause 7, the docking clause, is not used, and in Clause 11 the optional paragraph on an independent dispute resolution body is not used.

Every onward transfer to a subprocessor is made only where that subprocessor is bound by the Standard Contractual Clauses or by another safeguard listed in Clause 8.8 of those Clauses.

We have considered the laws of the United States that apply to us, as Clause 14 requires, and we have no reason to believe they prevent us from meeting our obligations under the Clauses. We are not a provider of electronic communication services within the meaning of section 702 of the US Foreign Intelligence Surveillance Act, and to date we have received no request from any government authority for your data. If that changes, or if we come to believe we can no longer meet those obligations, we will tell you without delay, and you may suspend the transfer or end this agreement.

For the United Kingdom, the ICO's International Data Transfer Addendum, version B1.0, is incorporated as well, and Part 2 of it, the Mandatory Clauses, applies. Table 1 is completed by the parties and the details in Annex I; Tables 2 and 3 by the Clauses and Annexes described above; in Table 4, the exporter may end the Addendum when the approved Addendum changes. If the ICO issues a revised approved Addendum, this one is amended to the revised version from the date it takes effect.

For Switzerland, references in the Clauses to the GDPR are read as references to the Swiss Federal Act on Data Protection, the competent authority is the Federal Data Protection and Information Commissioner, Swiss law governs the transfer, and nothing in the references to a member state is to be read so as to prevent a data subject in Switzerland from bringing proceedings in Switzerland.

If a court or an authority orders us to hand over your data, we will tell you unless we are legally forbidden from doing so, and if we are forbidden we will ask for permission to tell you and will tell you as soon as we may. We will challenge an order we consider unlawful, give the authority no more than it is legally entitled to, keep a record of the request, and, where the law allows, tell the person whose data was asked for.

We implement technical and organisational measures appropriate to the risk, as Article 32 of the GDPR requires, taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of the processing. Those measures are set out in Annex II.

We review the measures in Annex II at least once a year and whenever we make a change that affects them, and we update this page when the answer changes. We may change a measure, but we will not lower the overall level of protection.

Traffic between your browser and the service runs over TLS, and so do our calls to the subprocessors we reach over HTTPS. The encryption of the database connection is set by the connection string our deployment uses rather than fixed in our code, and encryption at rest belongs to our database and storage providers rather than to us. We do not pseudonymise your content: the service works on the text you give us, and pseudonymising it would break the thing you bought.

Annex II also has a second half that lists what we do not have. Please read that part. A measure named in a contract and missing from the product is worse than no measure at all, because you would have counted on it.

Access to production data is limited to the people who operate the service, and is used only to run it or to help you when you ask. That limit is a rule we keep, not a control the system enforces: as the last paragraph of this section says, we have no log of who looked at what.

Everyone with that access has given us a written undertaking of confidentiality or is under a statutory duty of confidentiality, and that obligation continues after they stop working on the service.

We keep your personal data confidential and we do not disclose it to anyone except the subprocessors in Annex III, on your instruction, or where the law requires — and where the law requires, we tell you first if we may.

Our application code runs under a database role that cannot bypass the isolation between workspaces, and a normal request runs with your workspace stamped on the connection. Three kinds of path step outside that pattern, and here they are. One creates your organisation's row when you first sign in. One reads a workspace's Google authorisation token, and one lists the workspaces with an active subscription, from background code that has no session to scope to. One acts for a workspace with no person behind the request at all: our payment provider's webhook, where the workspace comes from a request whose signature we verify, and the scheduler, which works from our own list of active subscriptions. None of them is a route a browser can reach, and none of them is used to read or write your business content.

We do not run access reviews, background checks or a log of who looked at what. If we ever do, it will be described here.

If we become aware of a personal data breach — any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, your personal data — we will tell you without undue delay and give you what we know: what happened, when, which data and which people are likely affected, what the likely consequences are, and what we are doing about it. If we do not have all of it at once, we will send what we have and follow up.

We will help you meet your own notification duties to your supervisory authority and to affected individuals, including by giving you the details you need for a notification.

We do not name a number of hours here, and here is why. Errors from our servers and from your browser now reach an error-tracking service, so a failure leaves a record we can find. We still have no security monitoring and no alerting: nobody is paged, and detection of an INCIDENT, as opposed to a crash, still means a person noticing. Promising you a twenty-four-hour clock we do not measure would be a worse answer than this one.

If a person asks you for a copy of their data, or asks you to delete it, you can act without waiting for us. Settings, then Account, exports everything in your workspace as a machine-readable file, and deletes the workspace on request. The export excludes the stored channel credentials and the Google authorisation token, because a copy of your data should not hand anyone a key to your accounts.

Only an owner of the workspace can run the export or the deletion. If you are a member and need either, ask your owner or email us.

Where you need more than that, we will help. Be aware of the limit: we cannot search for one individual across your brief, your messages and your published articles and remove just them. There is no such tool in the product. What you can do is edit the field, edit or take down the piece, and delete the workspace. If you give us a specific written instruction to correct, delete or produce a particular record, we will carry it out by hand within thirty days and at no charge.

If a request reaches us directly from one of your customers, we will not answer it ourselves. We will pass it to you without undue delay, because you are the controller and it is your call.

A person whose data we process for you may write to hello@vibrantmedia.ai. We will acknowledge them, tell them that we act for you, pass what they send to you, and keep you informed.

If you need to carry out a data protection impact assessment, or to consult your supervisory authority before you start, we will give you the information we have: this document with its Annexes, the Privacy Policy, and straight answers to your questions about how the product works. This section, together with the sections on security measures and security incidents, is how we assist you with your obligations under Articles 32 to 36 of the GDPR. We do not charge you for that assistance.

Annex I and Annex III together are our record of the categories of processing we carry out for you, kept as Article 30(2) requires. We have not carried out a data protection impact assessment of our own; when we do, we will say so here rather than let you assume it.

You can export your workspace at any time, and you can delete it. Deleting it removes your records from our database and your files from our storage — the article HTML we keep, the copies of published pages, generated images and the brand files you uploaded.

The database part of the deletion is all or nothing: if any table cannot be cleared, the whole thing is rolled back and you see an error rather than a false confirmation. Files are removed after the records, so a storage failure cannot leave records pointing at nothing, though it can leave the reverse — files already gone while the records are restored. Two smaller steps are best-effort and are reported to you separately: removing your own person-row, which stays as long as a membership in another workspace holds it, and removing your address from our newsletter list, which lives outside your workspace.

Some things survive, and this is the whole list. Your billing and plan record, and the row that ties your organisation to our payment provider, for as long as the law requires us to keep them. Your email address, but only while a membership in another workspace still holds it; once nothing holds it, it goes too. Today's date and the number of website reads it has used — we keep that counter as our own record, as controller, so that the daily cap cannot be cleared by the person it applies to, and it holds no content of yours. If you also subscribed to our newsletter from the footer of this website, that address is removed by the same click.

Deletion is not instant everywhere at once. Our database keeps a short recovery window — currently six hours — from which a copy could technically be restored. Until that window passes the copy stays under the confidentiality and security terms of this agreement and is used for nothing; after it passes, the deleted rows are gone from backups too.

What deletion does not reach, and you should know it. Your sign-in account with our identity provider is not deleted by this action; the delete signs you out and revokes your session, and if you want that account removed as well, ask us and we will do it by hand. The background-job engine keeps its own history of the jobs that ran for you, which includes the brief and the article text those jobs carried; we do not set how long it keeps them. Anything already received by the AI providers, the analytics provider or the payment provider is governed by their own retention terms, not by this button. Where a subprocessor holds a copy we cannot delete from here, we will ask it in writing to delete that copy when you ask us to, and we will tell you what it answers. We have no automated way to do any of this and we will not write a sentence claiming that we do.

When your subscription ends, the choice is yours: tell us to return your data and we will export it for you, or delete the workspace yourself. If you do neither, we will delete your workspace ourselves within ninety days of the end of the subscription, and we will tell you before we do. That deletion is a person running it, because there is no scheduled job anywhere in this product — but it is an obligation we owe you, not a courtesy.

If you would rather have your data returned than deleted, export it first — the export is the return. It is machine-readable JSON and it is available for as long as the workspace exists; once the workspace is gone we cannot produce it.

You may ask for the information you reasonably need to satisfy yourself that we are meeting these commitments, and we will answer in writing. If answering questions is not enough, you may audit us, including by an inspection carried out by you or by an auditor you mandate who is not a competitor of ours and who is bound by confidentiality, and we will contribute to it. Anything that goes past answering questions is at your cost and on reasonable notice, no more than once a year — unless an authority requires otherwise, or there has been a personal data breach affecting your data, or there is another concrete indication that we are not meeting these commitments.

We will make the same information available to your supervisory authority if it asks, and we will submit to an audit by it.

We do not hold a SOC 2 or ISO certification, and we will not imply one. No external penetration test has been carried out.

Two things we cannot show you, so do not plan an audit around them. There is no access log: the table for it exists in our schema and nothing writes to it. And while every piece is approved by a person before it publishes, we record that the approval happened, not which member of your team gave it.

Your rights under this agreement are these: to instruct us, and to have us process your data only on those instructions; to be told before a new subprocessor starts, and to object; to receive the information you need to demonstrate compliance, and to audit us; to have your data exported to you or deleted; to be told without undue delay about a personal data breach; and to end your subscription if we tell you we can no longer meet these commitments. Nothing in the Terms of Service limits these rights.

You decide what personal data enters the service, and you are responsible for having a lawful basis for it and for telling the people concerned, as your own privacy notice requires.

You confirm that you are entitled to name each web address you ask us to read, and that reading its public pages for you is lawful. We do not verify ownership of an address, and we read the one you type.

Do not put special categories of personal data or children's data into the service. As the Terms of Service say, the service is provided to businesses rather than to consumers, and you must be authorised to act for each business you register.

You review each piece before approving it, and approving it is what publishes it. If a piece contains personal data, that is your decision to publish, made with the text in front of you.

You manage who has access to your workspace and with what role. Sign-in is handled by our identity provider; we do not enforce two-factor authentication and we cannot report on whether your people use it. Any such policy is yours to set in your account with that provider.

For personal information covered by the California Consumer Privacy Act as amended, you are the business and we are your service provider. We receive personal information from you only to perform the services described in this agreement and the Terms.

We do not sell personal information and we do not share it for cross-context behavioural advertising. We never have. Our public website carries no third-party analytics, no advertising pixels and no fonts loaded from someone else's domain.

We do not retain, use or disclose your personal information for any purpose other than performing the services specified in this agreement, and not outside the direct business relationship between us, except as the Act permits. We do not combine it with personal information we receive from anyone else, except as the Act permits a service provider to do.

The specific business purposes are those set out in Annex I: producing marketing content for your business, checking it, storing it and the evidence of its publication, publishing an approved piece to a channel you connected, reading a website when you ask, and reading the analytics accounts you connect.

We will provide the same level of privacy protection to that personal information as the Act requires of you as the business.

Each of our subprocessors receives personal information only to perform its part of the service, under terms no less protective than these.

You may take reasonable and appropriate steps to ensure that we use the personal information in a manner consistent with your obligations under the Act, including by asking us the questions described in the section on audits, and reasonable steps to stop and remediate unauthorised use.

We certify that we understand the restrictions in this section and that we will comply with them.

Where you receive a verifiable consumer request to know, delete or correct, we will help you answer it as described in the section on helping you answer people who ask about their data, and we will pass a deletion instruction on to any subprocessor holding a copy.

We will tell you if we determine that we can no longer meet these obligations, and you may ask us to delete or return the personal information we hold for you — the deletion in the product does exactly that, with the exceptions listed in the section on deletion and return.

We do not offer the service to consumers in their personal capacity, and we do not have actual knowledge that we process the personal information of anyone under sixteen. We may, on your instruction, process the personal information of consumers whose data you put into the service. Where another United States state privacy law applies to you, we act as your processor or service provider under that law, and this section applies with equivalent effect.

Data exporter: you, the customer named in your subscription, acting as controller; your contact for data protection is the address on your account, and your activities relevant to the transfer are running your own marketing. Data importer: Vibrant Media, [legal entity name], [registered address], [company registration number], acting as processor and, for the data named below, as controller; its activities relevant to the transfer are operating this service; its contact for data protection is [name and position], hello@vibrantmedia.ai.

Neither party signs a paper copy. Your acceptance of the Terms of Service is your signature on these Clauses and their Annexes, and the date on this page is the date of signature and the start date of the Addendum.

Categories of data subjects: you and the people you invite into your workspace; your own customers, if you paste their words or details into the brief, into a message to the chief manager, or into a piece before approving it; and individuals named on the public pages of a website you ask us to read, such as staff listed on an about or contact page.

Personal data we process as your processor, coming from you: your workspace role, your messages to the chief manager, and the topic you type when you start a piece.

Personal data we process as controller, covered by Module One: your sign-in identity, your email address, your billing record and the usage records that show what your plan has consumed.

Personal data from your brief: business details that are not personal data as such — company, city, products, competitors, tone — plus whatever you type into the free-text field about what your customers say. That field is 600 characters of unfiltered text and may contain names or contact details if you put them there.

Personal data from a website you ask us to read: at most five public pages, up to 8,000 characters of each — the page's title, its meta description, up to 2,000 characters of its JSON-LD markup and its visible prose — which may contain the names, job titles, phone numbers and email addresses printed on those pages or declared in that markup, whether or not a visitor can see them. That text is not stored; it exists for the length of one request, and what remains is the address you named, recorded in the log of runs.

Personal data from analytics you connect: aggregated figures only. Search queries with clicks, impressions, click-through rate and position, and page addresses with clicks, impressions and position — up to a thousand rows of each: ten rows for the report you read on screen, and up to a thousand page rows over each of two twenty-eight-day windows when we audit your published pages for the clicks they are missing; one row of totals for the whole property, being clicks, impressions, click-through rate and average position; and sessions, total users and page views for a period. When we check whether two of your own pages are competing for the same search, we ask for those two together — the search query and the page address in one row, with that row's clicks, impressions and position — up to five thousand rows over ninety days, taken a thousand at a time; that pairing is a different composition from the two separate lists above, and it is read on demand and not stored, except for the one search you ask AI-SEO to judge: that search, the addresses of the pages competing for it and their figures go into the verdict card in your workspace and are erased with it. We receive no visitor-level data — no identifiers, no location, no device breakdown. When you approve a change to the search title and description of a page, we keep the figures we store for a page we edited — that page's clicks, impressions and average position over the twenty-eight days before the change, together with the same totals across the pages Search Console reports for the whole site — so that we can show you what the change did against what the rest of the site did anyway. That record is a snapshot of numbers, not of visitors, and it is erased with your workspace.

Personal data in credentials: the access details for the channels you connect, some of which identify a person or an account holder, and the authorisation token and email address of the Google account you connect.

Special categories of personal data: not requested and not required. You undertake not to enter them. We have no control that would detect them, so if they are entered despite that undertaking they are processed as ordinary content.

Frequency of the processing: continuous for as long as your workspace exists, and on your instruction for the one-off actions — reading a website, running a task, approving a piece.

Nature and purpose: producing marketing content for your business, checking it, storing it and the evidence of its publication, and publishing an approved piece to a channel you connected.

Duration: until your workspace is deleted, with the exceptions listed in the section on deletion and return. Nothing expires on a schedule.

Transfers to subprocessors: the subject matter, nature and duration of each are set out in Annex III.

Competent supervisory authority for the Standard Contractual Clauses: the authority of the EEA member state in which you are established; if you are not established in the EEA but have appointed a representative under Article 27, the authority of the member state where that representative is; and if neither, the authority of the member state where the data subjects to whom the transfer relates are.

Isolation between customers is enforced by the database, not by the application. Every record that belongs to a workspace carries its identifier, and the database refuses to return, insert, update or delete another workspace's rows — the rule is forced even for the table owner. Thirty-three tables carry that policy; four more that have no workspace column have their own; the two remaining tables are a catalogue of agent roles and a payment-webhook inbox, and neither holds customer data.

In a request made by a signed-in person, the workspace context is set only after the server has confirmed, in the same query, that this person is a member of that workspace, and the connection then drops to a role that cannot bypass the isolation. Both the identity and the workspace come from the verified session, never from anything the browser sends.

Two paths have no signed-in person at all: our payment provider's webhook, where the workspace comes from a request whose signature we verify, and our scheduler, which works from our own list of active subscriptions. Both are still confined to one workspace by the database rule; what they lack is a person to have vouched for the request.

Every change is checked automatically that no workspace-scoped table has been left out of the isolation rules — that check reads our schema and our policy file and fails the build if a table is missing. The behavioural test, which tries to read, insert, update and delete another workspace's rows against a real database and requires all four to fail, exists and passes, but it runs only where a database is configured and is skipped in our automated build. We run it by hand.

Roles and permissions: three roles — owner, admin, member — against nine named permissions, checked on the server at the entrance to every action that changes something. Only an owner can export or delete the workspace or manage billing.

Secrets never reach the browser. Every server action is a real trust boundary, and the modules that hold keys are marked server-only so that a mistake becomes a build error rather than a leak.

Channel credentials are encrypted by the application before they are stored, with AES-256-GCM and a fresh random nonce each time, using a key that never leaves the server. The encryption is bound to your workspace and the specific channel, so a stolen row cannot be opened in another workspace even by someone who got past the database. The key can be rotated without losing existing rows. If no key is configured, we do not store the credentials at all rather than store them in the clear, and the app tells you so.

When you ask us to read a website, our server resolves the address once, checks that it is a public address, and opens the connection to that exact address — so a redirect cannot send us into a private network or a cloud metadata endpoint. Only http and https, only ports 80 and 443, at most three redirects and never to another host, at most 512 KB and six seconds per page, at most five pages. The site's robots file is fetched first through the same guarded path, and we read nothing if it tells our reader to stay off the site.

Deletion is fail-closed in its database part: it either removes everything it is meant to remove or rolls back entirely, and files are deleted after records so that a storage failure cannot leave records pointing at nothing. The export excludes the stored channel credentials and the Google authorisation token by name.

Every page we serve carries strict security headers: no framing at all, no content-type sniffing, a content security policy that forbids framing and permits no third-party stylesheets or fonts, HSTS with a two-year max-age and preload, and camera, microphone and geolocation switched off. The site carries no analytics, no advertising pixels and no third-party fonts — the typefaces come from our own domain. One third-party script does load across the whole site when our identity provider is configured: its sign-in library, whose bot check runs on the sign-in and sign-up pages. That is why both of those providers appear in Annex III as seeing requests from visitors who never create an account.

Change control: every change runs the full check suite — types, lint, unit tests, build, and end-to-end browser tests — before it can reach the main branch, and the branch cannot be force-pushed or deleted. Dependency updates for patch and minor versions are merged automatically only after those same checks pass; major versions are a human decision.

Measures provided by our subprocessors rather than by us: encryption at rest of the database and of stored files, and the database's point-in-time recovery window. Those belong to our database and storage providers; we rely on their documentation and their terms, and we do not implement them ourselves.

Now the second half, which is the part most contracts leave out.

There is no access log. The table for it exists in our schema and nothing writes to it, so we cannot show you who did what inside our systems.

We do not enforce two-factor authentication for your people, do not check whether it is on, and cannot report on it. Sign-in is handled by our identity provider and any such policy is yours to set there.

The Google authorisation token is stored in the database protected by the isolation rules and by our provider's encryption at rest, but it is not encrypted by our application the way channel credentials are. We say this rather than write that all credentials are encrypted, which would be untrue.

Errors from our servers and from your browser reach an error-tracking service (Sentry, Annex III), so a crash leaves a record. We have no security monitoring and no alerting on top of it: nothing pages a person, and detection of an incident still means someone looking.

We hold no SOC 2 or ISO certification, and no external penetration test has been carried out.

We have never run a restore drill, so we do not state a recovery time or a recovery point objective. What we can state is the recovery window our database provider keeps, which is six hours.

Isolation is per organisation.

Nothing deletes itself. There is no retention job, no log rotation and no expiry; data stays until it is deleted by you or by us.

We have no way to detect personal data in what you type or in the text of a page we read, and no way to search for one individual across your data and remove just them.

We record that a piece was approved before publishing, but not which member of your team approved it.

The database isolation rules are applied by an operator step when the schema changes, not automatically on every deployment. The rules are real and tested; their application is a step a person runs.

Our rate limits are per running instance rather than shared across them, so we do not present them as a defence and do not count them among these measures.

Neon — our database. Receives everything stored in your workspace. Region: United States, AWS us-east-1, read from the provider on 14 August 2026.

Vercel — hosting and running the application. Handles every request, so any data in a request passes through it. United States.

Clerk — accounts and sign-in. Holds your name, email and sign-in identity, and we keep a copy of the sign-in identity, the email, and a workspace name we generate ourselves rather than copy from Clerk — either the words “My Business”, or the part of your email address before the @ followed by “'s workspace” when you sign in without an organisation. When it is configured, its script loads on every page of our website, so it also sees the request of a visitor who never creates an account. United States.

Anthropic — the model that writes your articles, and the models that do the shorter work. To write, it receives your business profile in full, including the free-text field about your customers, and the topic of the piece, and it returns the article. For the shorter work it receives: five lines of your brief — your city, your products, your competitors, the free-text field about what your customers say, and your website address — which go to the models that write your social posts, your outreach plans and your growth reports, and to the chief manager you chat with; your company name and your niche as well, to the models that write your social posts, your outreach plans and your growth reports, and your brand tone to the one that writes your social posts; the subject line of your social pack and of your growth report, which the product takes from your brief — the first of your products, or your niche if you listed none, or the words “your business” if you listed neither; your outreach plan is prepared without a subject line at all; when a social pack is written about an article you have just published, the model receives that article instead of a subject line from your brief — its title, its text up to 16,000 characters, and its public address; your messages to the chief manager and its replies to you, up to forty turns of the conversation, each up to 4,000 characters, together with a short line describing the state of your office; and, if you connect Google, the analytics figures as raw JSON, which includes the search queries and page addresses that account reports. On a deployment where no OpenAI key is configured, it also receives the text of the public pages of a website you ask us to read — the same pages, on the same limits, that OpenAI otherwise receives. United States.

OpenAI — the two independent reviewers that check every article for policy and for unsupported claims, the model that generates the image for a piece, and the model that reads a website when you ask us to. For review, it receives: the title and body of every piece we produce — an article, a social pack, an outreach plan or a growth report — twice each, once to each of the two independent reviewers, each of which sees the title in full and at most the first 32,000 characters of the body; and eight lines of your brief — your company name, your niche, your brand tone, your city, your products, your competitors, the free-text field about what your customers say, and your website address — as the set of facts to check against. For the image, it receives the subject of the image — which the product takes from your brief, being the first of your products, or your niche if you listed none, or the words “your business” if you listed neither — together with your company name, your niche, your tone and your brand colours; generating the image is part of the work you instruct, and which model does it is our choice of subprocessor. Nothing else from your brief goes with it, and no article text does. If no image model is configured, no image request leaves our servers at all. To read a website, it receives at most five public pages of the address you named, 8,000 characters of each — its title, its meta description, up to 2,000 characters of its JSON-LD markup and then its visible prose, assembled in that order and cut at 8,000 — and returns the draft profile with the quotes we then verify ourselves. The topic of an article is not sent to the two reviewers. Your company name, your niche and your brand tone are sent to them, and until 22 August 2026 they were not — that is a change, and here is why we made it. The reviewers are asked whether the article claims anything about your business that your brief does not support, and they were being given a list of your facts with those three left out. So they reported true sentences as unsupported: an article that said what your niche is was flagged for inventing it. Withholding them protected nothing in practice either, because your company name is written in the article itself and the reviewers receive that in full. It does not receive your messages to the chief manager or your analytics figures. United States.

Google — only if you connect them, we read your Search Console and Analytics with read-only access, and we store the authorisation token and the email address of that account. We also keep the figures we store for a page we edited, described in Annex I: when you approve a change to a page's search title and description, that page's clicks, impressions and average position over the previous twenty-eight days are written to our database alongside the same totals for the rest of your pages, and they stay there until your workspace is erased. United States.

Cloudflare — two things as well. Object storage holds the article HTML we keep, the copies of published pages — the whole HTML of the live page as your own site served it, up to 512 KB, including everything else on that page besides our text — generated images and the brand files you upload. And on our sign-in and sign-up pages a Cloudflare bot check runs, which sees the IP address and browser signals of anyone who opens those pages, including people who never create an account. That check appears only when our identity provider is configured. We do not choose the region for the stored files.

Inngest — the engine that runs the work in the background. In the event that starts a run it receives your whole business profile, the topic of the piece, the identifiers of your organisation, your user and your office, and the channel you chose. As the run progresses, its step state carries the article's title and text, its meta title and description, the names of any quality gates that failed, the storage keys of the files we saved, a fingerprint of the title and body, which model and which prompt version produced the piece, and what it cost. Two of our jobs run on a schedule rather than on your click — one grants monthly credits, one prepares a nightly draft — and each of them first asks our database for the list of every organisation with an active subscription and hands that whole list to the engine as the result of a step: for each organisation its id, the id of its office, the id of its owner, its plan and whether nightly drafts are switched on. The engine also sees an organisation's id inside the name of the step that works on it. Its own history retention is not something we set. United States.

Stripe — payments. From our code it receives only identifiers: your organisation id, the id of your office, the plan or pack id, the number of credits, and — once you have paid at least once — the customer id Stripe itself issued for your organisation. Your name, address and card details go to Stripe directly on its own checkout page; we never see full card numbers and we do not send it your email. United States.

DataForSEO — search demand. When your team needs a topic and nobody typed one, we ask it what people actually search for around what you sell. It receives a short phrase built from your brief — your niche and up to two of your products, one phrase per lookup — and returns the queries that contain that phrase, with how many times a month each is searched and how contested it is. If your brief names a city, we also send one phrase pairing that city with your first product, so the topics we pick can be ones your own neighbours search for. It receives nothing else: no article text, no analytics figures, no account details, and nothing at all about the people who visit your site. We pay for these lookups on our own account rather than yours, and we make at most one set of them per month for each version of your brief. United States.

Sentry — error tracking. When something in our software fails, it receives the error message, the code path that failed and which of our servers or which browser it happened in, so that we find out about the failure instead of you having to report it. It receives the identifiers we attach to the failure — which workspace and which piece of work — because without them we cannot tell whose run broke. It does NOT receive your account details, a recording of your screen, or the values of the variables in the failing code: those settings are off, and that is where your article text and your channel credentials would otherwise have appeared. Data is stored in the European Union.

These eleven are the whole list. We do not use an email sending service or any AI provider other than the three named above, and if that changes this page changes first.

Your own channels are not subprocessors. WordPress, Ghost and Shopify are destinations you name and control; when you approve a piece, its title and its body go to the destination you connected, on your instruction. When you approve a change to the search snippet of a page we published earlier, we send that destination the new title and description for that one post and nothing else — the body of the article is not sent and not altered. WordPress is the exception, and it receives less: its core has no SEO title field, so only the description is sent there, and the record we write for you says which of the two actually went. The image we generated is uploaded to the destination you connected when you approve the piece — WordPress puts it in your own media library, Ghost in its own storage — so that it appears with the article; Shopify does not receive it. Nine of the twelve channels the app lists send nothing at all — they are prepared but not wired to their platforms, and approving a piece for them records your decision and posts nothing. If you enter credentials for one of those nine, they are encrypted and stored and then sit unused; we mention it because a stored secret that does nothing is still a stored secret.

About the regions above: we have verified the database region ourselves. The others are United States companies and we rely on their own documentation and data processing terms for where they store data. Our hosting region and the location of stored files are account settings with those providers rather than something fixed in our code, so we describe them as they are configured today and not as a guarantee that cannot change.