--- title: "Polargate trust: data, security and legal facts" description: "POLARGATE, S.L., Madrid: where your data lives, who touches it, what you own, and what we do not have. No ISO 27001, no SOC 2, said plainly." url: https://polargate.ai/trust locale: en publisher: POLARGATE S.L. --- Trust # What your security team needs to know about Polargate This is the page for the person who has to approve us as a supplier. Who you are contracting with, where your data sits, who else touches it, what you own when we finish, what keeps running if we are not around, and the certifications we do not hold. No seals we have not earned. In short Polargate is POLARGATE, S.L., a Spanish company with a sole administrator, registered in Madrid. Your repository is yours from day one, infrastructure runs in your own accounts where the project allows it, and nothing we build needs Polargate to keep running. We do not hold ISO 27001 or SOC 2 and we have had no external penetration test. Security questionnaires are answered by the engineer who built the system, and yours goes in through the brief at /start. ## Who you are contracting with The contracting party is POLARGATE, S.L., a Spanish limited company with a sole administrator, registered and tax domiciled in Madrid, Spain, with an EU VAT number for work outside Spain. Contracts, invoices and liability sit with that company. Polargate is two people, not a large consultancy. Pedro Ciordia, founder and CTO, does the architecture, the build and the reviews; Andrés Ciordia, Chief AI Officer, leads the AI side. Specialists join per project. If your supplier process requires a vendor with a compliance department, this page tells you in five minutes whether we clear your bar, instead of in week three. ## Where your data lives, and who else touches it ### In your own accounts, where the project allows it We build on Postgres with row level security (Supabase), static hosting (Vercel) and a private Git repository. Where the project allows it, those accounts are opened in your name and billed to you, so the infrastructure is yours and not sublet from us. ### Subprocessors Everything we build has a short list of subprocessors: the database and backend host, the web host, the source host, the model provider used during delivery, an embeddings provider when the project includes semantic search, a web crawl provider when the project includes market monitoring, and the email transport. We do not publish one fixed global list, because the list depends on what we build for you. We send the named list, with the processing region of each service, in writing before you sign, and it becomes part of the contract. If a subprocessor changes during the engagement, you are told before the change, not after. ### Data residency We do not make a blanket claim that all data stays inside the EU. The region is chosen per project and written down before the first deploy. If EU only processing is a hard requirement, say so at kickoff: it changes provider choices, and it is cheap to decide before the first line of code and expensive afterwards. ## The code and the content are yours You own the repository from the first day, not on the last invoice. Nothing we build runs on a CMS of ours, on a licence you have to keep paying us, or on a runtime only we can operate. Sites are pre-rendered to static HTML and the content lives in your own database. At handover you receive the repository, ownership of the backend project, the DNS records and the secrets. The test we hold ourselves to is simple: another competent team should be able to pick the project up without calling us. Standard stack, standard deployment chain, documentation inside the repository. ## Continuity if Pedro is not available Straight answer: your product keeps running, because it does not run on anything of ours. The repository is yours, the infrastructure is in your accounts where possible, and the deployment chain is off the shelf. There is no Polargate licence server, no proprietary runtime and no key that we hold and you do not. What stops is new work, not the product. That is the real single operator risk, and we would rather write it on this page than let your risk team discover it. Ongoing support is contracted as a block of hours with a response window agreed in writing, and you see the consumption in your portal and in the footer of every support email, so you always know what is left. ## How we use AI in delivery, and what a person reviews We build with AI agents in the loop, then audit the result with several agents in parallel, and every finding is challenged by independent skeptical agents before we accept it. One recent audit ran 41 agents and produced 17 findings, each contrasted by two independent skeptics. In another check, a mechanical sweep of 300 cases showed that a rule we believed correct had been failing in 78 per cent of them; the corrected version came back with zero errors across the same 300. A person reviews and signs off, and a person triggers the production deploy by hand. On the platforms we run, tests run on every development and staging build. Nothing reaches production because a machine decided it was ready. Two limits worth stating plainly. First, code and documents you share with us are processed by the model providers we name to you, and their terms apply; we name them so your team can read those terms instead of taking our word for it. Second, secrets never go into a prompt or a repository. They live in an encrypted, audited vault behind a single gateway, every access is logged, rotation is versioned, and machine tokens are stored only as a hash. ## The controls we do have Each of these is a dated photograph of a system, not a permanent property of it. ### Tenant isolation Row level security is forced, and a guard discovers the tables that carry a tenant identifier instead of relying on a hand written list. In August 2026 it was watching 81 such tables and running in continuous integration, and the cross tenant test between two real tenants returned no leak on that run. ### Separation between clients in our own systems Our knowledge system keeps one client's material out of every other client through four independent layers: a database predicate, an application check with a test in CI, a table trigger and a revalidation of the request. As of 3 September 2026, 507 sources had been stopped by that wall before reaching any classifier. ### Auditing and spend limits Every call through our connector is logged, 8,463 of them at that same reading. An adversarial audit of our own access model produced 26 findings, 19 confirmed, all remediated and deployed. A second pass removed 13 row level security policies that granted global read to any internal user and added a ceiling of 200 AI calls per user per day. ### Secrets At the July 2026 reading, around 28 secrets lived in the vault, verified, with a per access audit trail and versioned rotation for rollback. Continuous integration reads from it to sign and publish applications, so no key has to be pasted anywhere. ### External eyes and web hardening An external consultant reviewed the security posture of one of our platforms in July 2026: 23 points, 11 closed at that reading. On sites we harden we serve HSTS, a Content Security Policy, X-Frame-Options, nosniff, a strict Referrer-Policy and a Permissions-Policy, and we remove server version fingerprints. ## The gap: no ISO 27001, no SOC 2 We do not hold ISO 27001. We do not hold SOC 2. We have not had an external penetration test. We do not publish a standard data processing agreement today. Writing any of that differently would be a lie your auditor would find anyway. What we do instead: we answer your questionnaire with the controls above, dated and with the evidence behind each one; we review and sign your data processing agreement as part of the contract; and we are open to a penetration test run by you or by your provider, at your cost and within a window agreed in writing. We would rather be tested than certified by adjective. We have no certification date to give you, because we have not started that process. When we do, the date appears on this page. If a certificate is a hard gate in your supplier framework, we will not clear it today, and you should know that now rather than in week three. ## Procurement and vendor onboarding ### What we can send you - Company identification for vendor registration: legal name, CIF, EU VAT number, registered address and bank details for invoicing. - A written architecture description of your project: components, data flows, where each piece runs, and the named subprocessor list with regions. - The access and secrets model: who can reach what, how access is granted and how it is revoked. - The deployment and rollback procedure, including who triggers production and how a release is reverted. - Your security questionnaire, completed. What we cannot send is anything that does not exist: certifications we do not hold and audit reports we have never had. ### How we answer a security questionnaire You get an acknowledgement with the name of the person who will answer it and a delivery date, and that date is the one we work to. A long custom questionnaire, or a supplier portal with its own forms, gets its date in that same first reply. The answers are written by the engineer who built the system, not by a compliance team. That is slower on volume and more accurate on detail, and it means the person who answers question 74 is the person who can change the thing question 74 is about. ### Who to talk to Pedro Ciordia, founder and CTO. Everything comes in through the brief at /start and lands on his desk. The same person handles the questionnaire, the architecture call, the contract review and any incident. There is no account manager layer in between. FAQ ## Questions, answered Do you hold ISO 27001 or SOC 2? No, and we have not had an external penetration test either. We do not have a certification date to give you, because the process has not started; when it does, the date goes on this page. What we offer instead is the dated controls listed above with their evidence, a completed security questionnaire answered by the engineer who built the system, your data processing agreement reviewed and signed, and openness to a penetration test run by you at your cost. Where will our data be stored, and does it stay in the EU? We do not make a blanket EU residency claim, because the answer depends on the project. The region of each service is chosen with you and written down before the first deploy, and it goes into the contract along with the named subprocessor list. If EU only processing is a hard requirement, raise it at kickoff: it changes provider choices, and it is cheap to decide before the build and expensive after. Who else can access our data, and how do we get the subprocessor list? You get the named list, with the processing region of each service, in writing before you sign, and it forms part of the contract. It typically covers the database and backend host, the web host, the source host, the model provider used during delivery, and, only when the project needs them, an embeddings provider, a crawl provider and the email transport. If a subprocessor changes during the engagement, you are told before the change. You use AI to build. Does our code or data go into a model? Yes, in part, and we name which providers so your team can read their terms rather than take our word for it. Two rules apply. Secrets never enter a prompt or a repository: they live in an encrypted, audited vault with a log of every access. And nothing ships on a machine's say so: a person reviews the work and a person triggers the production deploy by hand, with tests running on every build. Who owns the code and the content when the project ends? You do, from the first day rather than the last invoice. The repository is yours, there is no CMS of ours and no licence you have to keep paying us, sites are pre-rendered to static HTML and the content lives in your own database. At handover you receive the repository, ownership of the backend project, the DNS records and the secrets, so another competent team can take over without calling us. What happens to our system if Polargate stops operating? It keeps running, because it does not run on anything of ours: no licence server, no proprietary runtime, no key we hold and you do not. The repository is yours, the infrastructure sits in your accounts where the project allows it, and the deployment chain is standard tooling. What stops is new work, not the product. Polargate is two people plus specialists per project, and we would rather state that risk here than have your risk team find it. INITIATE ## Start the engine Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price. [Start your project](https://polargate.ai/start) · [Talk to us](https://polargate.ai/start#static-brief-heading)