Security built in, not documented afterwards.
The same standard on every product we build, ours included: access control, tenant isolation, audit logging, encryption and data residency, designed into the architecture where they're cheap, not 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.
Harden the application layer
Every query parameterised, every input validated, every output escaped, auth enforced server-side rather than trusted from the client, dependencies scanned on every build rather than at launch.
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.
- Secrets out of the codebase, out of git history, and scanned for on every commit
- No privileged key ever ships to a client or a browser, every credential scoped to what it actually needs
- Row-level isolation enforced in the database, verified with real authenticated requests, never a service key
- Authentication and authorization enforced server-side, never trusted from the client
- Every query parameterised, no string-built SQL, the injection class closed by construction
- All input validated and all output escaped before it touches a query or a page
- File uploads restricted by type and size, and scanned before they're stored
- Sessions and passwords handled correctly by default, hashed, HttpOnly, never rolled by hand
- Rate limiting and bot protection on anything that accepts a login or a form
- Security headers and forced HTTPS on every deploy, not added after launch
- Dependencies scanned on every build, not just checked once at launch
- Audit logging retained and queryable long after the fact
- Encryption in transit and at rest as standard
- Data residency. UAE or EU, stated in writing before the build
- Local model deployment for workloads that can't leave your infrastructure
- Written data-flow documentation you can hand to a customer or a regulator
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. This is the same checklist we run against our own products before they ship, not a different, lighter standard reserved for client work.
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.