Skip to main content

Sigil Cloud Privacy Policy

Effective date: October 21, 2026 Version: 1.1 Applies to: Sigil Cloud, the hosted service you sign up for at admin.netrunsystems.com/signup

Before you read this: two different sets of data

Sigil Cloud is a website and content platform. That means there are two different kinds of personal information in play, and the law treats them differently. Keeping them apart is the only way this policy makes sense.

1. Your account data. Your name, your email, your organisation name, your plan, your login. You gave this to us so we could sell you a subscription and run your workspace. We decide what happens to it, so we are responsible for it. In European terms, we are the "controller."

2. Your site data. Everything that flows through the websites you build on Sigil — the people who fill in your contact form, join your mailing list, or visit your pages. You decide what to collect and why. We just store and process it on your instructions. In European terms, you are the controller and we are your "processor."

This distinction matters to you practically. If one of your newsletter subscribers asks you to delete their data, that is your obligation and your decision — we will help you carry it out, but we will not decide it for you. If you ask us to delete your account, that is ours.

Note on processor terms. If you are subject to the GDPR or UK GDPR and you use Sigil to handle other people's personal data, the law requires a separate written data processing agreement between us — a privacy policy cannot do that job. See "If you are in the EU or UK" below.

1. What we collect about you (your account)

When you sign up, the signup form asks for exactly four things, plus your plan choice:

  • Your name
  • Your email address
  • Your organisation name (we turn this into your workspace address, e.g. yourorg.sig1l.com)
  • Which plan you want, and whether you want to be billed monthly or yearly

We also receive, automatically:

  • An anti-bot result. We use Cloudflare Turnstile to tell humans from scripts. Your browser sends Cloudflare a token and we ask Cloudflare whether it is valid. We send Cloudflare your IP address so it can make that judgement. We never see your Turnstile token in our logs, and we do not store the result.
  • Your IP address, used to rate-limit signups (five attempts per hour from one address). This is held in the server's memory only and is lost whenever the service restarts. It is not written to a database.

We record your agreement to the terms. When you tick the box agreeing to the Terms of Service and this policy, we store the fact that you agreed, when you agreed, the version of the terms in force, the exact sentence you were shown, and the IP address and browser user-agent the agreement came from. We keep that because a subscription that renews automatically has to be able to show what the customer actually consented to, and because you are entitled to the same record we have.

We never see your card. Payment happens on Stripe's own checkout page, not ours. Your card number, expiry and security code go to Stripe directly and never touch our servers. We receive back only an identifier for your Stripe customer record, an identifier for your subscription, and its status.

If you abandon checkout. The fields above are saved before you reach Stripe, so that your chosen workspace address is reserved while you pay. If you never complete payment, that record is marked expired after 24 hours, which releases the address — and the record itself is deleted 30 days later. See section 6.

While you use your workspace, we record:

  • Your password, stored only as a scrypt hash with a random salt. We cannot read your password and cannot tell you what it is.
  • When you last logged in.
  • An activity log of changes made in your workspace: who did it, what they changed, the web address they requested, the response code, how long it took, their IP address and their browser's user-agent string.

2. What we collect from visitors to your sites

This is your site data. We process it for you. There are three sources, and you should know about all three because they affect what you need to tell your own visitors.

Built-in page analytics ("Resonance")

Every page served by Sigil runs a small script that reports engagement to us. For each event we store:

  • Which site, page and content block it relates to
  • The event type (view, click, scroll depth, time in viewport)
  • A session identifier — a random value generated fresh in the browser on each page load
  • The referrer — the page the visitor came from
  • The visitor's user-agent string — which describes their browser, operating system and device

Two things we want to be precise about, in both directions.

What it does not do. This script sets no cookies and writes nothing to local storage. The session identifier is generated per page load and is not persisted on the device, so it does not follow a visitor from one page to the next or from one site to another. We do not store visitors' IP addresses in our analytics records.

What it does do. A user-agent string is a fingerprinting signal and a referrer can carry personal data in its query string. Under the GDPR these are personal data even though none of them is a name. We are not going to describe this as "anonymous analytics," because it is not.

This runs on every page and there is no way to switch it off. There is no setting in your workspace to disable it and nothing asks the visitor first — see section 5, which sets out what that means for you.

Things your visitors type in

If you add a contact form or a mailing-list signup to your site, we store what visitors submit:

  • Contact form: name, email address, subject, message, and anything your form passes through as metadata.
  • Mailing list: email address, optional name, subscription status, any tags you apply, and the date they subscribed or unsubscribed.

We store this so you can read it. We do not use it for our own purposes, we do not market to your subscribers, and we do not sell it.

Media you upload

Images and files you upload are stored in Amazon S3. You should understand how this bucket is configured, because it affects what you should put in it. The media bucket is readable by anyone who knows the address of a file, and files are served from a direct Amazon URL. Each site's files sit under their own path within the bucket, but a path is a filing convention, not a lock — it is not an access control, and it does not stop someone who has or guesses a file's address from reading it.

So: treat anything you upload to site media as published, even before you link to it. If you have a file that must stay private, site media is the wrong place for it.

Google Analytics — not running

No Google Analytics runs on Sigil-hosted sites, and no visitor data goes to Google. We have verified this on the production server: the measurement ID the page template would need is not set, it is not present in the running service, and the pages we serve contain no Google tag.

Two related points, because you may have been expecting otherwise:

  1. The Google Analytics field in your site settings is read by nothing. You can type a measurement ID into it and save it, and no page will act on it. It does not control what is injected on your pages. Treat it as inert until we say otherwise.
  2. The capability has been removed from the software. Until 20 October 2026 the page template contained code that could inject a single platform-wide Google tag if one server setting was filled in. That setting was never filled in on production, and the code has now been deleted, so no server setting can switch it on. Adding a Google tag or any other third-party tracker back would be a material change, and section 13 says what we will do first.

3. Email we send, and email you send

Email we send you is transactional: your welcome message with a link to set your password (that link expires after 24 hours), password resets, and notices about your account or billing. We send these through Amazon SES, from noreply@netrunsystems.com.

Email you send through Sigil — campaigns and newsletters to your own list — carries two tracking mechanisms you should be aware of, because you are the sender and the disclosure duty is yours:

  • An open-tracking pixel. A 1x1 invisible image at the bottom of each message. When a recipient's mail client loads it, we record that the message was opened.
  • Click tracking. Every link in the message body is rewritten to pass through our redirect service, so we can record which links were clicked, before forwarding the recipient on. The unsubscribe link is deliberately excluded.

Every campaign email includes a one-click unsubscribe link.

Your postal address, and why we will refuse to send without it. US law (the CAN-SPAM Act) requires every commercial email to carry the sender's valid physical postal address. There is a Mailing Address field in your site settings, under General. What you put there is added automatically to the footer of every campaign, next to the unsubscribe link.

If that field is empty, we refuse the send. The campaign reports zero sent and every recipient failed, with an error telling you to set the address. That is deliberate: sending without the address is the violation, and refusing is a configuration problem you can see and fix in a minute. We would rather hand you a failed send than a compliance breach.

4. Who else touches your data

These are the only companies that process personal data on our behalf. We have not listed anything we could not confirm from our own configuration.

| Who | What they do | Where | |---|---|---| | Amazon Web Services | Runs the servers, the database and the file storage; when you use the AI features, runs the model inference through Amazon Bedrock | US East (N. Virginia), us-east-1 | | Stripe | Takes payment, holds your card details, runs the billing portal | United States | | Amazon SES (part of AWS) | Delivers our email to you and your campaigns to your recipients | US East, us-east-1 | | Cloudflare | Anti-bot checks at signup and login (Turnstile); DNS for sig1l.com workspace addresses | United States / global network | | Google Workspace | Our own business email, which receives anything you send to a netrunsystems.com address, including rights requests | Google's network |

Some Sigil features connect to other services, but only if you choose to set them up — payment and commerce integrations, for example. When you connect one, you are sending data to that company under their terms, and you should read them.

Beyond that list, we disclose personal data only when we are legally required to, or if the business is sold or merged — in which case we will tell you before your data moves.

We do not sell your personal information, and we do not share it for cross-context behavioural advertising.

5. Cookies, tracking, and a gap we are not going to hide from you

Sigil uses a cookie to keep you logged in to your workspace. That one is strictly necessary — without it the product does not work.

Now the part that matters, stated as precisely as we can.

There is no cookie consent banner on Sigil-hosted sites, and there is no control that would produce one. No banner exists anywhere in the product, there is no setting that enables one, and nothing asks your visitors for permission before the page analytics in section 2 collect their referrer and user-agent. If you are looking for that switch: there is not one. A switch labelled "Cookie Consent Banner" did appear on the site settings screen until 16 October 2026. It never did anything, and we removed it rather than leave a control that implied a protection it did not provide.

What that does and does not mean for you. The page analytics set no cookies and store nothing on the visitor's device, so the specific European rule about storing information on someone's equipment — the one everybody calls the cookie rule — is not the live issue here. The live issue is the ordinary GDPR one: a referrer and a user-agent string are personal data, so if you have visitors in the EU or UK you need a lawful basis for collecting them and you need to tell your visitors it happens. Your own privacy notice has to cover it, because Sigil will not do it for you.

Practically, today:

  • The analytics are on for every page and cannot be turned off, by you or by your visitor.
  • There is no consent mechanism in Sigil you could use to gate them, for this or for anything else you add to your site.
  • If your own compliance position requires consent-gated analytics, or an opt-out, Sigil cannot currently give you either. Assume that before you buy, not after.

We would rather lose a sale than have you find this out from a regulator.

6. How long we keep things

| What | How long | |---|---| | Your account and workspace content | For as long as your subscription is active | | Your account after you cancel | Until you ask us to delete it — we do not currently delete it automatically | | Abandoned signups (you started, never paid) | Marked expired after 24 hours; deleted after 30 days | | Your record of agreeing to the terms | For as long as your account exists, and afterwards for as long as a billing or renewal dispute could be raised | | Workspace activity log | No automatic deletion is in place | | Page analytics events | No automatic deletion is in place | | Uploaded media | Not deleted when a workspace is removed, unless deletion is specifically requested | | Encrypted database backups | Held in Amazon S3 |

About abandoned signups. If you start signing up and never complete payment, your name, email address and organisation name sit in our database. After 24 hours the record is marked expired, which releases the workspace address you had reserved. Thirty days after it was created, the record is deleted outright by a scheduled job — not archived, not anonymised, deleted. Thirty days is a grace period for support questions and payment disputes, not an open-ended hold. If you would rather not wait, email us and we will delete it now.

About the other "no automatic deletion" rows. We are not going to claim a retention schedule we do not operate. Where the table says there is none, there is none, and the data stays until someone asks us to remove it. If you need a specific retention period for your own compliance, ask us and we will tell you honestly whether we can meet it.

7. Where your data is, and how it is protected

Sigil Cloud runs on a single server in Amazon's US East (N. Virginia) region, with the database and file storage in the same region. Some of our own internal and backup systems run on hardware we own in the United States. If you are outside the United States, your data will be transferred to and stored in the United States.

What actually protects it:

  • Traffic is encrypted in transit. Every public address is served over HTTPS with certificates from Let's Encrypt, terminated at our edge.
  • Passwords are hashed, using scrypt with a per-user random salt, and compared in constant time. We cannot recover your password.
  • Separation between customers is enforced in the database itself, using PostgreSQL row-level security. Rather than relying on application code to remember to filter by customer on every query, the tables that hold customer data carry policies attached to the table, which restrict each query to the rows belonging to the customer identity attached to that request. On most of those tables the policies are additionally set to apply to the table's owner as well — PostgreSQL calls this "forced" — so the restriction holds even for the database role our application connects as, and not only for ordinary users.
  • Database backups are encrypted before they are stored in Amazon S3.
  • Signup and login are protected by Cloudflare Turnstile and rate limits.

Now the honest limits of that, because an overstated security section is worse than none:

  • We hold no security certifications. We are not SOC 2 audited, not ISO 27001 certified, and not HIPAA certified. We have not had a penetration test. Do not put protected health information into Sigil, and do not rely on us in a context that requires any of those. If a vendor questionnaire asks, the answer is no.
  • Three tables carry a deliberate exception, and we will name them. cms_users, cms_tenants and cms_pending_signups have row-level security enabled but not forced. Because our application connects as the role that owns those tables, and PostgreSQL lets an owner bypass policies on a table that is not forced, the database is not the last line of defence for those three — application code is. The reason is structural, not neglect: all three have to be read or written before there is any customer context to filter by. Logging in means finding a user by email address before we know which workspace they belong to; listing the workspaces you can switch between means looking across workspaces by design; and a signup record is created before a customer exists at all (that table's policy denies access outright, and our own code is what reads it). We will not tell you that one customer can never see another's data. We will tell you that the database enforces the separation on the tables that hold your content, that these three carry a known and deliberate exception, and that no system is perfectly secure.
  • We do not claim whole-disk encryption. Our backups are encrypted before they leave the server, which is verified. We are not going to make a broader "encrypted at rest" claim we have not confirmed end to end.
  • The media bucket is readable by anyone with a file's address. See section 2.

8. Your rights, and exactly how to use them

Depending on where you live you may have the right to get a copy of your personal data, correct it, delete it, take it elsewhere in a portable format, and object to or restrict how we use it. We honour these requests from anyone who asks, wherever you live, rather than checking whether a particular law covers you.

How to make a request — and what will actually happen.

Email daniel@netrunsystems.com with what you want and which workspace it concerns.

We want to be clear about the mechanism, because the honest version is more useful than a reassuring one:

  • A person handles your request by hand. There is no self-service button for rights requests. Someone runs it against the database directly.
  • We will respond within 30 days. If a request is genuinely complicated we may take longer, and we will tell you why before the 30 days are up.
  • We will verify who you are before acting, normally by replying to the email address on the account. We are not going to delete a workspace because someone asked us to from an unrelated address.
  • There is a partial export you can run yourself, through the API. While your subscription is active, an admin or editor signed in to your workspace can call GET /api/v1/sites/{siteId}/export/json for a bundle of that site's settings, pages, content blocks and active theme — and, if asked, the catalogue records for your media. GET /api/v1/sites/{siteId}/export/csv gives you the pages as a spreadsheet. Two caveats, both important: there is no button for this in the admin interface, so you have to call it or ask us to; and it is not everything. It does not include your mailing-list subscribers, your contact form submissions, your page analytics, your account record, or the uploaded files themselves — only their catalogue entries.
  • For anything that export does not cover, ask us and we will assemble it by hand, in a structured, machine-readable format you can load somewhere else — not an archive only we can open.
  • If you ask us to delete your account, we delete it. We do not substitute encrypting it and keeping the key: that is not deletion, and we are not going to describe it as deletion.
  • To delete a workspace, its subscription must be cancelled first. Our tooling deliberately refuses to remove a workspace with a live subscription, so that nobody ever deletes a paying customer by accident. Cancel in Billing (or ask us), then ask for deletion.
  • Uploaded media needs to be named. Media files are not removed automatically with a workspace. If you want your uploaded files deleted, say so and we will delete them too.
  • Export before you cancel. Once your subscription ends you lose the signed-in session the export needs, and we have no mechanism that keeps it available afterwards. If you want your content, take it while the account is live, or ask us and we will do it manually.

If you are one of our customers' site visitors — if you filled in a contact form or joined a mailing list on a site that happens to run on Sigil — your request belongs with the business whose site you used, not with us. They decide what happens to that data. If you contact us anyway, we will pass it to them and tell you we have.

You will never be charged, downgraded or treated worse for exercising any of these rights.

9. If you are in the EU or UK

Our legal grounds for using your account data:

| What we do | Why we are allowed to | |---|---| | Create and run your workspace; take payment | Performance of our contract with you (Art 6(1)(b)) | | Send transactional email about your account | Performance of our contract | | Keep a record of your agreement to the terms | Performance of our contract, and our legal obligation to be able to evidence consent to a recurring charge | | Block bots and abuse at signup and login; keep an activity log | Our legitimate interests in keeping the service secure (Art 6(1)(f)) | | Keep billing and tax records | Legal obligation (Art 6(1)(c)) |

Your data goes to the United States. We have not yet documented a transfer mechanism for that — Standard Contractual Clauses, or reliance on the EU–US Data Privacy Framework through our suppliers. That work is outstanding. If a lawful transfer basis is a condition of you buying, ask us before you sign up rather than after.

If you use Sigil to process other people's personal data, Article 28 requires a written data processing agreement between us, covering our instructions, our staff, our sub-processors, security, breach notice, and what happens at the end. We do not have one to give you yet. That is a gap on our side, not yours. Ask for it and we will tell you honestly where it stands.

Automated decision-making: we do not make automated decisions about you with legal or similarly significant effects.

Complaints: you can complain to us first, and you have the right to complain to your national data protection authority, or the ICO in the UK.

10. If you are in California

We post this policy publicly and date it, as California law (Business and Professions Code section 22575) requires of any online service that collects personal information from Californians — a duty that applies regardless of our size.

Categories of personal information we collect about account holders: identifiers (name, email, IP address); commercial information (your plan, subscription status and payment history); and internet activity (your workspace activity log, including user-agent and request details).

We do not sell personal information and we do not share it for cross-context behavioural advertising. We have never done so.

We do not knowingly collect or use sensitive personal information as California defines it.

You may have the right to know, delete, correct, and limit use of sensitive information, and to opt out of sale or sharing — though we do not sell or share, so there is nothing to opt out of. Use the email address in section 8. We will not discriminate against you for asking.

Do Not Track: we do not respond to browser Do Not Track signals. The page analytics described in section 2 run regardless of a Do Not Track header.

Third parties tracking across sites: we do not permit third parties to collect personal information about your activity across different websites through Sigil-hosted pages.

11. Children

Sigil Cloud is a business product sold to businesses. It is not for children, and we do not knowingly collect personal information from anyone under 13. If you believe a child has given us personal information, email us and we will delete it.

If you build a site on Sigil that is directed at children, the obligations under COPPA and similar laws are yours, and you should know that the page analytics in section 2 run on every page and cannot be disabled.

12. If something goes wrong

If personal data in our care is exposed and it presents a risk to people, we will investigate, contain it, and notify those affected and the relevant regulators as the law requires — including the GDPR's 72-hour deadline for notifying a supervisory authority where it applies. If the data affected is your site data, we will tell you promptly, because the duty to notify your own users and regulator is yours and you cannot meet it if we are slow.

13. Changes to this policy

We will update this page as the product changes — and several things in it are written to be fixed. If we make a change that materially affects your rights or how we use your data, we will email the address on your account before it takes effect. Adding a Google tag or any other third-party tracker to Sigil-hosted pages would be such a change. The version number and date at the top tell you which version you are reading.

14. Who we are, and how to reach us

Netrun Systems, Inc. A C Corporation 2325 Maricopa Hwy Ojai, CA 93023 United States

Privacy questions and rights requests: daniel@netrunsystems.com

That address is read by a person and is the right place for anything in this policy.