Security built in, not documented afterwards.
Access control, tenant isolation, audit logging, encryption and data residency, designed into the architecture, where they're cheap, rather than retrofitted after a customer's security questionnaire, where they aren't.
Security work has a timing problem.
Security is inexpensive when it's part of the original design and painful when it's a reaction to a deal stalling on a questionnaire. Almost everyone does it in the second order, because the first order has no forcing function.
The specific issues we find repeatedly are consistent and unglamorous. Tenant isolation enforced in application code rather than the database. Audit logs that roll over before anyone needs them. Secrets in shared documents. Service keys used where a scoped key belongs. And no written answer to where data physically sits.
There's a testing trap worth naming because it catches careful teams: verifying row-level security using a service key. Service keys bypass RLS entirely, so the test passes, everyone relaxes, and the policy was never actually working. Verification has to use an authenticated request at the same privilege level as a real user.
We're deliberate about language here. We build to align with common practice and with GDPR principles. We do not issue certifications, and any vendor telling you a build makes you 'compliant' is overselling what engineering can do.
The same discipline extends to documents and filings, invoices, contracts and certificates parsed on arrival, validated against your existing records, and turned into compliant outputs with a human approval step before anything is submitted externally. The UAE's move to structured e-invoicing over the PEPPOL network is the current version of this.
How it works, step by step.
Map where the sensitive data actually is
Usually more places than expected, logs, backups, analytics, error reports and third-party tools all quietly accumulate it.
Enforce isolation at the database
Row-level security policies rather than application filters, so a forgotten clause isn't a breach.
Verify with authenticated requests
Never with a service key, which bypasses RLS and will falsely confirm a broken policy works.
Get secrets into proper management
Out of documents and repositories, with rotation possible without a code change.
Build audit logging that survives
Retained long enough and structured so it's queryable when someone asks about a decision a year later.
Write down the data flow
Where data sits, who can reach it, how long it's kept, how it's deleted. Written before a regulator or a customer asks.
Four things people assume this is.
A compliance certification
We build to align with the practices certifications require. Obtaining one involves your policies and an auditor, not a vendor's claim.
Penetration testing
A specialist discipline. We'd refer you to someone who does it properly rather than sell a shallow version.
A policy document exercise
Documents describing controls that aren't implemented are worse than nothing, they create false confidence.
Security theatre
Controls that inconvenience staff without reducing risk get worked around, which leaves you less secure than before.
Concretely, what's delivered.
- Row-level isolation enforced in the database, verified with real authenticated requests
- Audit logging retained and queryable long after the fact
- Secrets management with rotation possible without a deploy
- Data residency. UAE or EU, stated in writing before the build
- Encryption in transit and at rest as standard
- Local model deployment for workloads that can't leave your infrastructure
- Access review, who can reach what, and whether they still need to
- Written data-flow documentation you can hand to a customer or a regulator
- Document and filing automation, invoices, contracts and certificates parsed and validated against your records, with a human approval gate before anything is submitted
- UAE e-invoicing readiness, structured output ready for the PEPPOL-based mandate as it reaches your entity
Why we can say this.
The RLS verification point isn't theoretical for us. On our own platform work we've hit the exact failure it describes, a policy that recursed and silently broke every authenticated code path, which testing with a secret key had happily confirmed as working. We now verify with authenticated anon-key requests as standard, and check for it in every audit.
Usetta, our own multi-tenant product, runs on the same discipline. It carries real customer data across tenants, so isolation is enforced at the database rather than trusted to application code, access is scoped and audit-logged, and secrets sit outside the codebase with rotation that doesn't need a deploy, before it went anywhere near a client.
What this won't do.
- We don't issue certifications. Compliance is determined by your policies and your auditor.
- We don't do penetration testing. It's a specialist field and you should hire a specialist.
- Security isn't a project that finishes. Dependencies age, staff change, access accumulates. It needs review.
- No system is unbreachable. What's achievable is raising cost to an attacker and limiting blast radius, anyone promising more is selling.
Straight answers.
Can you make us GDPR compliant?
We can build to align with GDPR principles, data minimisation, residency, access control, deletion, audit trails. Compliance itself is an organisational determination involving your policies and your auditor, and any engineering vendor claiming to confer it is overstating what a build can do.
Can data stay entirely inside our infrastructure?
Yes. For sensitive workloads we run models locally so nothing is sent to an external provider. It costs more to run and it's the right call for some regulated work.
Do you do penetration testing?
No. It's a specialist discipline and we'd rather refer you to someone who does it properly than sell a shallow version. What we do is build systems that stand up when someone competent tests them.
What's the most common problem you find?
Tenant isolation enforced in application code instead of the database, closely followed by RLS policies that were verified with a service key and therefore never actually tested.
Can you help with a customer security questionnaire?
Yes, both answering it accurately and fixing what it exposes. Those are usually two pieces of work and we'd separate them honestly.
How long does this take?
An audit is about a week. Remediation depends entirely on what it finds, and we'd rather scope that after looking than guess now.
Do you handle UAE e-invoicing and PEPPOL compliance?
Yes, this is where document automation and compliance engineering meet. We built a connector called Qode that converts invoice data into the structured format the network requires. The honest sequence is fixing your master data first and connecting second, a connector fed bad data produces validated, network-delivered nonsense. We wrote up what the mandate actually changes for a finance stack, worth reading before a scoping call.
Anqor is a small studio, so you deal with the person who builds it. If this isn't the right fit for your business, I'd rather say so on the first call than sell you something you don't need.
LinkedIn →How is your tenant isolation actually enforced?
If the answer is 'in the application code', that's worth a conversation this week rather than after a customer's questionnaire.