Compliance & Security

01Our stance

You can verify everything on this page by asking. Nothing here is aspirational.

02What applies to us

We are established in Spain and process personal data within the European Union, so the following apply directly.

Our lead supervisory authority is the Agencia Española de Protección de Datos (aepd.es).

03What does not apply — and what we do not claim

This section exists so nobody has to email and ask. The answer to "are you SOC 2?" is no.

If your organisation requires any of the certifications above from its suppliers, hfs2s does not currently meet that bar. That is a straight answer rather than a soft one, and we would rather give it now than at the end of a procurement process.

04GDPR in practice

Roles

We are the controller for your account, your workspace and the logs. Where you build an app that collects personal data from its own users, you are the controller of that data and we are your processor, acting on your instructions to host it.

Lawful bases

Named per purpose in the privacy policy: contract for running the service, legitimate interests for security and the audit log, legal obligation for accountability records.

Data subject rights

One person answers these, usually the same day.

Access, rectification, erasure, restriction, portability and objection are all honoured at [email protected], within one month, at no charge. Portability is unusually easy here: your app is a git repository and we hand you the whole thing, history included.

Data protection by design — Art. 25

• The signup rate-limiter holds your IP address only for as long as the check takes and never stores it, because a public form does not need a permanent record of who loaded it.
• The activity log records acts, not contents — never a token, never a sign-in URL, never a message body.
• The mail log stores subject lines and delivery status but never bodies, because a body can contain a live sign-in link.
• Our access gate is default-deny: a path nobody has explicitly made public is private.

Data Protection Officer

Not required. We do not carry out large-scale systematic monitoring, and we do not process special category data on a large scale, so the Art. 37 triggers are not met. Data protection questions go to [email protected].

Records of processing — Art. 30

We are under 250 employees, but the processing is regular, so we do not rely on the small-organisation exemption. The privacy policy is a public statement of substantially the same content.

Automated decision-making

None. Nothing here produces a legal or similarly significant effect about you automatically. Account approval is a human decision made by a person.

05Where your data lives

At rest: Spain. Your account record, your workspace, your app's code and history, your uploaded files, your chat transcript and our logs are all held within the European Union, and no third party beyond those in §06 holds a copy.

Your data stays in the EU. It leaves only when a model has to read it.

In transit: outside the EEA, when a model has to think. Chat messages, briefs, document text and code are sent to AI providers abroad, because that is where the model runs. This is the single most important thing on this page for anyone assessing us, which is why it is also stated plainly in the privacy policy rather than only here.

Transfer mechanisms, and the honest state of that paperwork, are in privacy §07 and in §08 below.

06Subprocessors

The complete list. There is no other.

We will publish changes to this list here. If you have an account and we add a subprocessor that receives your content, we will email you.

07Security measures

The technical and organisational measures we actually operate, in GDPR Art. 32 terms. Every item is implemented today.

Identity and access

• Sessions are carried in a cryptographically sealed cookie that cannot be forged or altered, marked HttpOnly so no script can read it, Secure so it never leaves over plain HTTP, and SameSite=Lax against cross-site submission.
• Email sign-in links are single-use and expire in 15 minutes.
• The Google sign-in is protected against cross-site request forgery by a one-time state value with a 10-minute life.
• The authorisation gate is default-deny: anything not explicitly published requires a valid session. Being signed in is not sufficient — an account must also be approved.
• Administrative surfaces re-check identity and role independently on every request, rather than trusting that an earlier check ran.

Isolation between customers

• Every workspace runs in its own isolated environment, with its own storage and its own resource limits.
• Every route that names a workspace resolves ownership first, and returns an identical "not found" for "not yours" and "does not exist" — so the API cannot be used to enumerate who owns what.
• Our own credentials are never made available inside a customer's workspace. A workspace receives only what it needs to run, and nothing else.
• Our session cookie is stripped from every request before it reaches a customer's app, and an app is blocked from setting a cookie in our namespace on the way back out.

Data handling

• TLS in transit for every request. Our database is not reachable from the public internet, and not from any customer's workspace.
• Secrets never appear in code and are masked in logs. The audit log is append-only and holds no tokens or credentials.
• Data is written so that an interrupted write cannot leave it corrupted, and a failed read is never treated as an empty one — the failure mode that would otherwise let the system overwrite data it could not read.
• External input is validated at the boundary with a schema validator; request bodies are never trusted or blind-cast.
• The public signup form is rate-limited per IP address.

Change management

• An automated test suite and a full type check must pass before anything is deployed.
• Dependencies are kept deliberately minimal — new ones require justification — which keeps the supply-chain surface small.
• No third-party script runs on any public page.

08What we have not done

• No high-availability guarantee. We do not operate redundant infrastructure. If the service goes down, it stays down until we bring it back.
• No customer-restorable backups. Version history inside your workspace is real and works, but there is no off-site backup we can restore from if your workspace is lost. Keep your own copy of anything that matters.
• Subprocessor paperwork is incomplete. Signed data processing agreements and Standard Contractual Clauses with the providers in §06 are in progress and not finished.
• No third-party audit. No SOC 2, no ISO 27001, no penetration test by an external firm.
• Account deletion is manual. Erasure is complete and irreversible when done, but it is performed by us on request rather than by a button you press.
• No per-customer encryption at rest. Your data is not encrypted with a key unique to you.
• No formal registered entity is published. hfs2s currently trades under a personal name; a registered company name and address will be published here when one exists.
• Uptime is not monitored by a third party and there is no public status page or SLA.

If one of these is a blocker for you, say so — it moves up the list.

09If something goes wrong

Breach notification. If personal data is breached in a way that risks people's rights, we notify the AEPD within 72 hours of becoming aware, as GDPR Art. 33 requires, and tell affected people directly without undue delay where Art. 34 requires it. If we are a processor for data you control, we tell you without undue delay so you can meet your own deadline.

Reporting a vulnerability. Email [email protected] with enough detail to reproduce it. We aim to acknowledge within two working days. We will not pursue legal action over a vulnerability found in good faith, confined to your own workspace, and not exploited against other customers or our infrastructure.

There is no paid bug bounty. We will credit you if you would like to be credited.

10For your due diligence

If you are assessing hfs2s for an organisation, this page plus the privacy policy is designed to answer most of a standard security questionnaire. For anything else — a DPA to sign, a specific control, an architecture question — write to [email protected] and you will get a direct answer from the person who built it, including "no" where the answer is no.

Small enough that the person answering your questionnaire wrote the code.

We update this page whenever the position changes. The version and effective date at the top say which text you are reading.