Privacy Policy

1. Scope and who we are

PostSignOff is operated by [LEGAL ENTITY NAME], LLC ("we", "us"). This policy covers the PostSignOff application, the public forms it generates on your behalf, and this marketing site. It does not cover the social platforms you connect, which handle data under their own policies.

Two roles run through the whole document, and keeping them apart is the point of it.

• We are the controller of your own account data — the "business" under US state law. Your name, email address, login credentials, billing identifiers, usage records, support correspondence, and visitors to this marketing site. We decide why and how that is processed, and this policy is our notice to you about it.
• We are the processor of what you put into the product about other people — the "service provider". The leads you capture and, above all, the Medicare beneficiary information in permission-to-contact (PTC) consent records. You are the controller of that data. We process it only on your instructions, never for our own purposes, and we do not sell it or build profiles from it. A consumer whose information you collected should come to you first — see section 14.

Your contract with us is the Terms of Service. /data is the operational walkthrough of what we store and where; /compliance explains how the review works.

2. The short version

• We do not sell your personal information and never share it for targeted or cross-context behavioural advertising. There is no ad business here to feed.
• No analytics or tracking scripts — none on this site, none in the application. Fonts are self-hosted, so loading a page exposes your IP address to no third party.
• Everything runs in the United States, on Google Cloud in us-central1.
• Your content is not used to train AI models. Drafts are processed through OpenAI's API; under OpenAI's API policy, API content is not used to train their models by default. We train nothing on it either.
• You keep what you create. Hitting a plan limit, downgrading, or cancelling never deletes your content.
• Lead and beneficiary data is yours, not ours. We hold it as your processor.
• Rights requests are handled by a person, not a portal. There is no self-service deletion button and no automated export endpoint. Email us or use the contact form; we verify who you are and handle it manually within the deadlines in sections 12 and 13.

3. Information we collect

Account and identity

Your name, email address, an avatar image URL, account status, and any suspension reason an administrator records. Password sign-in stores a scrypt hash, never the password. Signing in with Google, Facebook, or X stores the tokens that provider issues us. We hold short-lived email-verification and password-reset tokens with their expiry times. Each signed-in session is stored on our servers with its token, your IP address, and your browser user agent, and expires 30 days after creation.

Content you create

Drafts and edited versions, rich text, the first-recorded version history, sign-off text, topics, private notes, the text as published, platform error messages, the post IDs and URLs platforms return, and who approved each post. Each distinct version of a post's content also carries an immutable compliance-review record: the findings, the rule citations, and — where a finding was acknowledged — who acknowledged it, when, and against which attestation text.

Media

Images and video you upload or generate, with the storage key, URL, thumbnails, MIME type, file size, dimensions or duration, alt text, editing state, source, and lifecycle status.

Brand and platform connections

Brand name and description, voice configuration (tone, style, topics to cover and topics to avoid), logo and website URLs, the public token that serves your forms, and your branding and compliance settings. For each connected social account: the account name, the platform's identifier, and OAuth tokens, encrypted at rest.

Lead and beneficiary information you collect through the product

This is what we hold as your processor, and the most sensitive material in the system.

• Captured contacts. Email address, name, phone number, consent timestamp, a verbatim snapshot of the consent text shown, submission count, when last seen, and their IP address and user agent.
• PTC consent records. First and last name, address lines, city, state, ZIP, an internal beneficiary key, your NPN and name as the agent, the reasons and methods of contact consented to, the TCPA consent flag with a verbatim snapshot of the clause text and a cryptographic hash of it, per-recipient data-sharing consents, the disclosures rendered, the signature method, the typed signature and attestation, the signature and expiry dates, the IP address and user agent, the input method, locale, channel, time spent on the form, and a revocation block.
• Agent identity on your form. Agency legal name, DBA, agent full name, NPN, phone number, email address, service area, named data-sharing recipients, and the form slug.

Billing

Stripe customer, subscription, and subscription-item identifiers, plan and price identifiers, and the raw Stripe webhook payloads we receive, which may contain a billing name, email address, and address. Card details never touch our servers — payment happens entirely on Stripe-hosted pages.

Technical and log data

Application logs record the request method, path, status, and duration — no IP address, no user agent, no request bodies. Logs of outbound calls record the integration, operation, host and path, duration, and outcome, never secrets or bodies. Every mutating administrative action is audit-logged with the actor identifier and email address, the action and target, the path, the status code, redacted metadata, a request identifier, and the IP address. Where an error-tracking DSN is configured, Sentry receives exception messages and stack traces, breadcrumbs from instrumented external calls, and a user and tenant identifier.

In one place: IP addresses are stored with sessions, administrative audit records, captured contacts, contact-form submissions, and PTC consent records. User agent strings are stored with sessions, captured contacts, contact-form submissions, and PTC consent records.

Marketing site and contact form

This site sets no cookies. A message sent through the contact form stores your name, email address, company if given, phone number if given, your message, the consent checkbox and the verbatim consent text you agreed to, and your IP address and user agent.

4. Where the information comes from

• You — sign-up, brand setup, drafts, notes, and support messages.
• Your end users and consumers — people completing a capture or PTC form supply their information directly, but they are giving it to you, through our software.
• Connected platforms — X, LinkedIn, Facebook, Instagram, Reddit, and TikTok return account identifiers, the profile data needed to post on your behalf, access tokens, and the results and engagement metrics of what we publish for you.
• Payment processing — Stripe returns customer and subscription identifiers and sends webhook events about your subscription.
• The device in use — IP address and user agent at sign-in and at each public form submission.

5. How we use information

We use information to run the service, keep it secure, bill for it, and meet our own legal obligations. We do not build advertising profiles from it and we do not sell it. Where the GDPR or UK GDPR applies to processing we carry out as controller, these are our lawful bases.

6. AI processing of your content

PostSignOff sends content to OpenAI to generate drafts and images, suggest image prompts, and run the compliance review. This is a hard dependency of the AI features.

What is sent: post drafts and your edited content; your brand name and voice configuration — tone, style, topics to cover, topics to avoid; the topic or context text you supply, your sign-off, and your branding configuration; the names of the platforms you are targeting; image prompts and your brand colour palette; and, for review, the rule pack, any firm-specific custom rules, and the full text of the post.

No end-user names or email addresses are included in these payloads, and no user or account identifiers are attached to them. The one thing we cannot filter is what you type — a draft is sent as written, so do not paste a consumer's personal information into the body of a post.

Under OpenAI's API policy, API content is not used to train their models by default. We do not use your content to train any model of our own.

AI output can be wrong. Generated text may be inaccurate or non-compliant, and the review can miss things. It assists supervision; it does not certify or guarantee regulatory compliance. Nothing publishes until a human approves it, and that human is you.

7. When we share information

We do not sell personal information, and we do not share personal information for cross-context behavioural advertising or targeted advertising, as those terms are defined under the California Consumer Privacy Act and comparable state laws. We never have.

We share information with service providers who process it for us under contract. Which ones apply depends on configuration and which integrations you enable — this is what may be involved, not what always is. The current complete list, with the data each one receives, is kept at /data.

• Google Cloud Platform — hosting, database, container images, media storage, secret management. Effectively all data at rest sits here.
• OpenAI — generation and compliance review, as in section 6.
• Stripe — subscriptions and payment; your email address and a tenant identifier.
• Resend — transactional email; the recipient address and name and the rendered message, including contact-form notifications.
• Social platforms you connect — X, LinkedIn, Meta (Facebook and Instagram), Reddit, and TikTok receive post text, media, and the account identifiers needed to publish. Where an operator has enabled it instead, Zernio brokers publishing and receives post content, short-lived signed media URLs, and platform account identifiers.
• Cloudflare Turnstile — bot protection on the public capture and PTC forms only, when configured; the visitor's IP address.
• Sentry — error tracking, only when a DSN is configured; exception data and a user and tenant identifier.
• Pexels — stock media search, when enabled; your search query.
• A WhatsApp relay — pending-approval digests containing post content, sent to a destination phone number, only where an operator configures it.

We also disclose information where the law requires it: subpoenas, court orders, and other lawful requests from regulators or law enforcement; to establish or defend legal claims; to our professional advisers under duties of confidentiality; and where we reasonably believe it necessary to protect someone's safety or investigate fraud or a security incident. Where we are permitted to tell you about such a request, we will. If we are involved in a merger, acquisition, financing, or sale of assets, information may transfer as part of it, and an acquirer remains bound by this policy for the transferred information until you have notice of any change.

8. Cookies and similar technologies

This marketing site sets no cookies at all. There are no advertising cookies, no analytics cookies, and no cross-site tracking anywhere in PostSignOff. Fonts are self-hosted rather than pulled from a CDN, so no third party sees your IP address because you loaded a page here.

The application sets four cookies, all strictly necessary to sign you in and keep you signed in. All are issued by our authentication library, are HttpOnly, use SameSite=Lax and Path=/, and in production carry the Secure flag and a __Secure- name prefix. Because we set no non-essential cookies, there is no consent banner to click through.

Three values stay in your own browser and are never transmitted to us: smm-theme (your light or dark preference, used by the application and this site) and smm-brand-id (the brand you last had selected) in local storage, and smm-connection-banner-dismissed in session storage.

One exception. On the public capture form and the PTC form, if bot protection is enabled, the visitor's browser loads the Cloudflare Turnstile widget, exposing their IP address, user agent, and any Cloudflare cookies to Cloudflare. It is the only third-party browser request in the product, and it exists to keep automated submissions out of your consent records.

9. How long we keep information

We are specific where the system is specific, and we would rather tell you a period is still being set than invent one.

• Account and content — kept while your account exists. Deleting a post does not erase it: posts are never hard-deleted, and deletion moves the post to a rejected status while the record remains. A pending draft whose scheduled time passes without approval moves to an expired status rather than being removed.
• Media — trashed media is purged 30 days after it reaches the trash. The purge deletes the file itself from storage but retains a tombstone row recording the storage key, URL, alt text, and dimensions, so the history of what existed survives. Archived media is never purged. Temporary uploads never attached to anything are removed after 24 hours.
• Sessions — expire 30 days after creation.
• Captured lead contacts — deletable outright on request; that row is genuinely removed. A deliberate exception, because these are third-party individuals who must be able to get out.
• PTC consent records — append-only by design. A consent is valid for 12 months from the date of signature, and corrections create a new record rather than altering the old one, because a record that can be edited afterwards is worthless as evidence. They are retained long-term as the customer's compliance record, there is no automatic deletion, and requests about them are handled as described in sections 14 and 16.
• Closing an account — performed manually by an administrator on request. It marks the account deleted and clears active sessions; by itself it does not erase the content in the account. If you want the content removed too, say so and we will handle that manually.

For everything else — application and audit logs, contact-form submissions, billing webhook records, expired sessions and tokens, usage records — we keep information for as long as needed for the purposes described in this policy and to meet legal and recordkeeping obligations. No fixed period is defined for those categories today. A formal retention schedule is being finalised and this section will be updated with specific periods once it is.

10. Security

• Publishing credentials are encrypted at rest with AES-256-GCM and a per-value random initialisation vector; production refuses to start without the key. The honest limit: tokens issued by a login provider when you sign in with Google, Facebook, or X are stored by our authentication library and are not covered by that application-level encryption.
• Passwords are hashed with scrypt. We cannot read yours and never store it.
• Tenant isolation is enforced at the database. PostgreSQL row-level security is enabled and forced on brands, campaigns, posts, media, templates, platform accounts, analytics, subscriptions, compliance reviews, capture forms, contacts, and PTC data, and the application's database role cannot bypass it.
• TLS protects data in transit, with platform-managed certificates.
• Media storage is private, with public access blocked at the bucket. When a file must be handed to a posting provider we mint a signed URL that expires in 15 minutes.
• Rate limiting on sign-in, sign-up, password reset, email verification, AI generation, public form submissions, the contact form, and webhooks; inbound webhook signatures are verified against the raw request body.
• Secrets live in Google Secret Manager. Media URL signing is keyless, so there is no long-lived signing key to leak, and deployments use workload identity federation rather than a stored service-account key.
• Security headers with a content security policy, and an allowlist for cross-origin requests.

We do not offer multi-factor authentication today. That is a real gap and we are not going to dress it up. Until it ships, use a long unique password, or sign in through a social provider on which you have already enabled two-factor authentication.

No method of transmission or storage is perfectly secure, and we cannot guarantee absolute security. That sentence is not a licence to under-invest: the controls above are commitments, and if we become aware of a breach affecting your personal information we will notify you and, where the law requires it, the relevant regulators.

11. Where your information is stored and international transfers

All of it is stored and processed in the United States, on Google Cloud in the us-central1 region — the application, the database, the media bucket, and this marketing site alike. Some providers in section 7 operate globally and may process data elsewhere while providing their services.

PostSignOff is designed for and sold to licensed insurance professionals in the United States, and is not directed to individuals in the European Economic Area, the United Kingdom, or Switzerland. If you access it from one of those regions anyway, your information is transferred to and processed in the United States. For personal data covered by the GDPR or UK GDPR we rely on the European Commission's Standard Contractual Clauses, with the UK International Data Transfer Addendum where applicable, alongside encryption in transit and at rest and the tenant isolation above. If you need a data processing agreement, ask through section 19 and a person will work through one with you.

12. Your privacy rights — US state laws

If you live in California, Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, or another state with a comprehensive privacy law, you have rights over the personal information we hold about you as controller. The list varies by state but generally includes: to know what we collect and access it; to have it deleted; to have inaccuracies corrected; to receive a portable copy; to opt out of the sale of personal information, of sharing for cross-context behavioural advertising, of targeted advertising, and of profiling with legal or similarly significant effects; to limit our use of sensitive personal information; and not to be discriminated against for exercising any of them. Several states also give you a right to appeal a refusal.

On the opt-out rights: we do none of those things. We do not sell personal information, share it for cross-context behavioural advertising, use it for targeted advertising, or profile with legal or similarly significant effects. Nor do we use or disclose sensitive personal information beyond providing and securing the service, so a request to limit that use changes nothing — though you are welcome to make one and we will confirm our position in writing. We run no financial-incentive programme, and exercising a right will not affect your price or service. PostSignOff has not yet operated commercially, so there is no prior-twelve-month disclosure history beyond the categories in section 3 and the business purposes in section 7.

How to make a request, honestly described. There is no privacy portal, no "download my data" button, and no automated deletion endpoint. Every request is handled by a person.

1. Email the address in section 19 or use the contact form. Say which right you are exercising and give us enough detail to find your records.
2. We verify your identity first, normally by confirming you control the email address on the account, and may ask for more where the request is sensitive. We will not create an account for you just to verify you, and we use verification information for nothing else.
3. We respond within 45 days. Where a request is complex or you have sent several, we may extend by a further 45 days, telling you within the first 45 why.
4. An authorised agent may act for you with your written permission or a valid power of attorney. We may still contact you to confirm you authorised it.

Some information we may be required or permitted to keep — billing records needed for tax, security and audit logs, and consent records held on a customer's behalf. If we cannot fully honour a request, we will tell you which parts we declined and why.

13. Your privacy rights — GDPR and UK GDPR

Where the GDPR or UK GDPR applies and we act as controller, [LEGAL ENTITY NAME], LLC is the controller and you may: access the personal data we hold about you; have inaccurate data rectified; have data erased in the circumstances the law provides; restrict our processing; receive your data in a portable, machine-readable format; object to processing based on our legitimate interests, including at any time to processing for direct marketing; and withdraw consent where processing rests on consent, without affecting processing already carried out.

The path is the same manual one as section 12: email or the contact form, identity verification, a person handling it. There is no automated export or erasure endpoint. We respond within one month, extendable by up to two further months for complex or numerous requests, telling you within the first month if we need them.

You may lodge a complaint with your supervisory authority — in the United Kingdom, the Information Commissioner's Office. We would rather you came to us first, but that is your right, not a step you owe us. Because the service is offered to licensed insurance professionals in the United States and is not directed to individuals in the EEA or the UK, we have not appointed an Article 27 representative; if that changes, so does this section. Where we act as processor we assist our customer in responding, but the request belongs to them — see the next section.

14. If you are a consumer whose information an agent collected

If you filled in a form for an insurance agent — a permission-to-contact form, or a request to be contacted about Medicare plans — and you have arrived here looking for the company holding your information, this section is for you. We make the software the agent used. The agent or agency is responsible for your information; we hold it for them and act only on their instructions.

• Contact the agent or agency you dealt with first. Their legal name, the agent's name, and usually a National Producer Number and phone number appear on the form you completed and on the confirmation you were shown.
• If you contact us instead, we will help. We forward your request to the relevant customer and assist them in responding. Where we can identify you, we will tell you who we forwarded it to.
• Withdrawing your consent must be directed to the agent. The agent is who contacts you, and the agent is responsible for honouring a withdrawal and stopping calls, texts, emails, or mail. Consent records here are the agent's compliance record and are deliberately not something we alter on our own initiative — changing them would destroy the evidence of what you were shown and agreed to. Telling us is not a substitute for telling the agent.

15. Health information and HIPAA

[LEGAL ENTITY NAME], LLC is not a HIPAA covered entity and is not a business associate. We do not sign business associate agreements. Customers must not upload protected health information, Medicare beneficiary identifiers, Social Security numbers, or clinical or health-status information toPostSignOff.

That is a design position, not a disclaimer bolted on afterwards. The PTC form deliberately does not collect date of birth, Social Security number, health status, or Medicare number, and the contact channels it can represent are limited to phone, text, email, and mail. There is no field anywhere in the product for a diagnosis, a medication, or an enrolment record.

We recognise that the fact someone completed a Medicare permission-to-contact form may itself be treated as sensitive information under some state privacy laws, and we treat consent records accordingly: processed only on the customer's instructions, never for our own purposes, never sold or shared for advertising. If protected health information is uploaded despite the prohibition above, it is outside the intended use of the service and in breach of the Terms of Service; tell us and we will work with the customer to remove it.

16. Telephone consumer protection and consent records

The obligation under the Telephone Consumer Protection Act, and under the CMS marketing rules beside it, belongs to the customer. The customer calls, texts, and emails consumers, and it is the customer's licence on the line. We do not place calls or send text messages to consumers on any customer's behalf.

What we do is store the artifacts of a consent so the customer has a record: a verbatim snapshot of the clause text the consumer was shown and a cryptographic hash of it, the typed signature and attestation, the signature date and the resulting 12-month expiry, the IP address and user agent, the input method, locale, and time spent on the form. Records are pinned to the immutable version of the form the consumer actually saw, so they cannot drift when the form is later edited. That is an evidentiary record and nothing more — we make no representation that it satisfies any carrier, regulator, or court.

Revocation is a manual process the customer owns. Recording a withdrawal of consent is not a self-service action in the product today. If a consumer tells us they have withdrawn consent, we forward it to the relevant customer and assist, but the customer must honour it through its own processes — stopping the outreach, updating its own records, and meeting whatever deadline it committed to on the form. The Terms of Service place that responsibility on the customer, and the product says so on screen.

17. Children's privacy

PostSignOff is a business tool sold to licensed insurance professionals. It is not directed to anyone under 18, and we do not knowingly collect personal information from children. There is no date-of-birth field and no age check anywhere in the service, so we perform no age verification and cannot detect a minor from the data we hold.

If you believe a child's information has been submitted through a form built withPostSignOff, contact us using section 19 and we will locate the record, remove it, and notify the customer whose form collected it.

18. Changes to this policy

We may update this policy as the product changes — and it will change, because several of the manual processes described here are meant to become real features. When we do, we post the updated version on this page and change the effective date shown at the top, currentlyJuly 28, 2026. If a change materially affects how we handle personal information, we give account holders notice by email to the address on the account, or in the product, before it takes effect. Continuing to use PostSignOff after a change takes effect means you accept the updated policy.

19. How to contact us

Privacy questions, rights requests, and complaints go to the contact form. Suspected vulnerabilities or security incidents go to the contact form. Either way you can use the contact form — a person reads every message.

Postal notices to the controller named in this policy:

[LEGAL ENTITY NAME], LLC
[STREET ADDRESS], [CITY], North Carolina [ZIP]

Related pages: the Terms of Service, the plain-English data handling summary, and how the compliance review works.