Privacy Policy - ruledoc.io

Status: DRAFT (non-lawyer prepared). Review carefully before publishing. Effective date: [REVIEW: set effective date on publish, e.g., 2026-05-15] Last updated: 2026-05-10 Version: 1.0-draft

1. Who we are (Art. 13(1)(a) GDPR)

This Privacy Policy describes how RFPvault (postal address pending PostNord boxadress registration, Stockholm, Sweden) ("ruledoc", "we", "us", "our") collects, uses, and protects your personal data when you use ruledoc.io (the "Service").

ruledoc.io is a B2B SaaS platform that parses customer-supplied firewall configurations and produces compliance reports (NIS2, PCI-DSS, ISO 27001, CIS Benchmarks, NIST CSF, SOC 2) and PDF audit-evidence packs.

RFPvault (postal address pending PostNord boxadress registration, Stockholm, Sweden)
Contact: privacy@ruledoc.io

We are the data controller (Art. 4(7) GDPR) for personal data processed about visitors to our website and users of our Service. For personal data that you upload inside firewall configurations (for example, usernames inside policy rules), we act as a data processor (Art. 4(8) GDPR) on your behalf - see our Data Processing Agreement (DPA) for the controller/processor terms.

2. Data Protection Officer (Art. 13(1)(b), Art. 37 GDPR)

We have not appointed a Data Protection Officer. ruledoc.io does not engage in "large-scale" processing of personal data, nor in "large-scale" processing of special-category data (Art. 9) or criminal-conviction data (Art. 10), and we are not a public authority. The Art. 37(1) triggers do not apply.

For all privacy-related questions, contact privacy@ruledoc.io.

If our processing scale changes such that Art. 37 applies, we will appoint a DPO and update this Policy.

3. What personal data we collect and why (Art. 13(1)(c), Art. 6 GDPR)

We process the following categories of personal data:

We do not use behavioural advertising, profiling, or any cookies for marketing or analytics. We do not sell or share your personal data with third parties for their own marketing.

3.1 What we do NOT collect

• We do not knowingly collect special-category data (Art. 9): health, biometric, political opinion, etc.
• We do not knowingly process children's data (Art. 8): the Service is B2B only.
• We do not use third-party analytics, advertising trackers, or social-media plugins.

3.2 Note on firewall configuration content

When you upload a firewall configuration, that file may contain personal data of your end users (typically: usernames in source-user-based policy rules). For this data, you are the controller and we process it on your documented instructions under our DPA (Art. 28).

All configuration parsers actively strip secrets (pre-shared keys, plaintext and hashed passwords, RADIUS / LDAP / TACACS shared secrets, API keys, certificate private keys, SNMP community strings, SSH host keys) before constructing the intermediate format. Stripped values are replaced with deterministic placeholders of the form __STRIPPED_<KIND>_<NAME>__ and recorded in an audit log (<vendor>_raw.stripped_secrets) that includes the kind and original byte length but never the original value. The audit log is queryable by you (the controller) for compliance evidence; the original plaintext is irrecoverable from our storage.

Two further defence-in-depth layers run on top of the per-vendor stripping:

1. Evidence-snippet sanitisation - the auditor evidence_snippet attached to each Finding is line-filtered to mask any residual secret-like substring that the per-vendor stripper missed.
2. LLM-input sanitisation - the prompt sent to our third-party LLM sub-processor (Anthropic) for rule-description generation is scrubbed of any residual secret-like substring before transmission.

You should still treat configurations as confidential before upload and avoid uploading credentials when they are not required for compliance reporting, but in normal operation the persisted intermediate format, the auditor evidence snippets, and the LLM input contain zero plaintext credentials. See docs/security/secret-stripping.md in the source repository for the full per-vendor coverage matrix.

4. Legitimate-interests assessment summary (Art. 13(1)(d))

For purpose #4 (service security), we rely on legitimate interests. Our interest is in keeping the Service available, secure, and free from abuse. We have assessed that this interest is not overridden by your rights and freedoms because (a) the data involved (IP, user-agent, request logs) is necessary for security and routinely used across the SaaS industry, (b) retention is short (30 days), and (c) we do not use this data for any secondary purpose.

5. Who we share your data with (Art. 13(1)(e))

We share your personal data only with the sub-processors listed in our public Sub-processor List, summarised below:

• Hetzner Online GmbH (Germany) - hosting infrastructure
• Anthropic, PBC (United States) - large-language-model service used for generating natural-language descriptions of parsed firewall rules
• [ADD WHEN INTEGRATED] Stripe - payment processing
• [ADD WHEN INTEGRATED] Transactional-email provider - service emails

We may also disclose data when required by law (Art. 6(1)(c)), to enforce our Terms of Service, or to protect our rights, property, or safety.

We do not sell or rent your personal data.

6. International data transfers (Art. 13(1)(f), Art. 44–49 GDPR)

Most processing takes place in the EU (Hetzner, Germany - covered by GDPR directly).

The following sub-processors are located outside the EU/EEA:

• Anthropic, PBC - United States. Transfers are protected by the Standard Contractual Clauses (EU Commission Implementing Decision (EU) 2021/914, Module Two: Controller-to-Processor) supplemented by additional technical measures (limited data scope: parsed UIF rule JSON only - no raw configuration text, no secrets).

You can request a copy of the SCCs in force by contacting privacy@ruledoc.io.

7. How long we keep your data (Art. 13(2)(a), Art. 5(1)(e) GDPR)

You may delete uploads earlier from the Service interface, or request deletion of all personal data by emailing privacy@ruledoc.io (subject to legal-retention obligations such as accounting records).

8. Your rights (Art. 13(2)(b), Art. 15–22 GDPR)

You have the right to:

• Access (Art. 15) - request a copy of personal data we hold about you
• Rectification (Art. 16) - correct inaccurate or incomplete data
• Erasure (Art. 17) - request deletion of your data (subject to legal-retention obligations)
• Restriction (Art. 18) - restrict our processing in certain circumstances
• Data portability (Art. 20) - receive your data in a structured, machine- readable format
• Object (Art. 21) - object to processing based on legitimate interests
• Withdraw consent (Art. 7(3)) - withdraw any consent you have given (does not affect processing already done)
• Not be subject to automated decision-making (Art. 22) - we do not perform automated decision-making with legal or similarly significant effects on you

To exercise any right, email privacy@ruledoc.io. We will respond within one calendar month of receipt (Art. 12(3)), extendable by a further two months for complex or numerous requests.

We will verify your identity proportionately to the request - typically by confirming the email address on the account.

8a. How we fulfil access and erasure requests (DSAR procedure)

When you exercise your Art. 15 (access) or Art. 17 (erasure) rights, the request is handled through our internal Data Subject Access Request (DSAR) procedure, which has the following guarantees:

Identity verification. We verify the request originates from the account holder by checking the From: address against the registered account email. Requests sent from any other address are routed back to the registered email for confirmation before any data is exported or deleted.

Response time. We acknowledge every DSAR within five working days and complete the request within the GDPR one-month statutory window (extendable by two further months for unusually complex requests, with notification).

Access (Art. 15) - what you receive. A ZIP archive containing:

• A README.txt listing each section and record count
• user.json - your account row
• organization.json - your organisation row
• configs.json, findings.json, compliance.json, reports.json - every config you have uploaded and every finding/result we have derived
• audit_log.json - every audit-log event referencing your user or org
• support_tickets.json, support_messages.json - every support conversation you have started
• subscriptions.json, usage_tracking.json, early_access_signups.json - every billing record, quota counter, and marketing-leads row we hold
• password_resets.json, email_verifications.json, user_invites.json - every auth-flow scratch row tied to your account

Binary columns (e.g., previously generated report PDFs) are summarised as <bytes:N> placeholders to keep the archive readable. We will send the binary content on request.

Erasure (Art. 17) - two modes.

• User-level erasure (pseudonymisation). Your users row is preserved for legal-retention reasons (audit-log integrity, billing-record FK chain), but every identifying field is nulled: email, display name, password hash, IP address, third-party identity provider ID, and any other free-text personal field. The username is rewritten to deleted-{id}. Auth-flow scratch rows (password_resets, email_verifications, and any open invites you authored) are hard-deleted. After this operation the account cannot be logged into and contains no recoverable personal data.
• Organisation-level erasure. Hard-deletes every config you have uploaded, every finding/compliance result/report derived from those configs, removes the raw-config files from disk, pseudonymises every member account in the same way as user-level erasure, and rewrites the organisation row's name to deleted-org-{id}. Audit-log entries are preserved (legal basis: GDPR Art. 17(3)(e), legal claims) but reference an opaque, no-longer-identifying organisation name.

Records of every DSAR action. Every export and every erasure is recorded in our audit_log table under category='privacy', with a timestamp, the operator who actioned the request, and the size/scope of the export or the row counts affected by the erasure. Records are retained for the lifetime of the table.

Where the tooling lives. DSAR exports and erasures are performed by our ruledoc-admin operator CLI; the source is published on our public GitHub repository so the procedure is auditable end-to-end. Operators run the CLI under a personal SSH login that is itself audit-logged.

9. Right to lodge a complaint (Art. 13(2)(d), Art. 77 GDPR)

You have the right to lodge a complaint with the supervisory authority. As we are established in Sweden, the lead supervisory authority is:

Integritetsskyddsmyndigheten (IMY) - the Swedish Authority for Privacy Protection Box 8114, SE-104 20 Stockholm, Sweden Phone: +46 8 657 61 00 Email: imy@imy.se Web: https://www.imy.se/

You may also complain to the supervisory authority of your habitual residence, place of work, or place of the alleged infringement.

10. Security (Art. 32 GDPR)

We protect your personal data with appropriate technical and organisational measures, including (without limitation):

• Encryption in transit (TLS 1.2 or higher on all public endpoints)
• Encrypted database storage and encrypted off-site backups
• Stripping of pre-shared keys and credentials from parsed configurations where the parser supports it
• Access controls (least privilege; multi-factor authentication on administrative accounts)
• Logging of authentication and administrative actions
• Vulnerability monitoring of dependencies
• Documented incident-response procedure (see section 11)

No system can guarantee absolute security; we make no warranty that the Service is invulnerable.

11. Personal-data breaches (Art. 33–34 GDPR)

If we become aware of a personal-data breach affecting your data, we will:

• Notify the supervisory authority (IMY) within 72 hours where the breach is likely to result in a risk to your rights and freedoms (Art. 33).
• Notify you without undue delay, and within the timeframe contractually agreed in our DPA (within 24 hours of becoming aware), where the breach is likely to result in a high risk (Art. 34).
• Document the breach and our response (Art. 33(5)).

12. Cookies and similar technologies

We use only strictly-necessary cookies (session authentication). We do not use analytics, advertising, or tracking cookies. Strictly-necessary cookies do not require consent under ePrivacy Directive Art. 5(3). See our Cookie Policy for the full list.

13. Children's data (Art. 8 GDPR)

The Service is intended for B2B use by adult professionals. We do not knowingly collect data from children under 16. If you believe we have inadvertently done so, contact privacy@ruledoc.io and we will delete the data.

14. Automated decision-making (Art. 22 GDPR)

We do not carry out automated decision-making (including profiling) that produces legal or similarly significant effects on you. The compliance-report generation that the Service performs is an advisory input to your own compliance assessment; the Service does not make legally-binding decisions about any individual.

15. Changes to this Policy

We may update this Policy. The "Last updated" date at the top reflects the most recent change. Material changes will be communicated to account holders by email at least 30 days before they take effect.

Older versions are kept on request via privacy@ruledoc.io.

16. Governing law

This Privacy Policy is governed by the laws of Sweden and the GDPR (Regulation (EU) 2016/679).

[REVIEW] Items requiring your attention before publication:

• [REVIEW] Operator legal entity name and registration number
• [REVIEW] Registered address
• [REVIEW] Effective date
• [REVIEW] Confirm retention tiers (free vs paid, 90d vs 365d) match your launch plan
• Support and privacy email addresses confirmed: support@ruledoc.io, privacy@ruledoc.io
• [REVIEW] Confirm SCC module / module 2 reference once Anthropic transfer paperwork is in place

DRAFT NOTICE. This document is a defensible non-lawyer draft. It uses the GDPR Art. 13/14 template from a recognised compliance methodology, applied to ruledoc.io's actual processing. Substantive legal review is recommended before public deployment, especially of sections 5, 6, 7, and 14.