PCI DSS readiness
Make the audit smaller before you try to pass it. Scope found in your own code, controls mapped, evidence that survives the year.
We are the engineering vendor, not your assessor. The attestation is signed by a QSA or by you, and nothing here changes that. What we change is how much there is to assess and how much of last year's work you can reuse. Scope comes out of your repositories and your traffic instead of a workshop, controls get mapped to the requirements with the gaps named, evidence is collected once and kept current, and the drift that undoes all of it between audits gets watched.
Where it fits
The problem
The expensive part of PCI DSS is not the controls, it is not knowing where a primary account number goes. One forgotten log line, one debug field, one legacy batch job, and a system nobody meant to include is in scope. So the assessment covers everything, the evidence pack gets rebuilt from scratch every year, and the answer to how a card number reached that table is a conversation rather than a record.
What we build
Discovery that reads your code and your traffic and produces the actual data-flow map, then the design changes that shrink it. Hosted fields, a client-side token request and a tokenized boundary keep card data out of your servers, which is what moves an assessment from SAQ D toward SAQ A. Whatever stays in scope gets its controls mapped requirement by requirement, with the evidence for each one named and where it comes from.
How we engage
Senior engineers work against your systems, and everything they build stays yours: the data-flow map, the control matrix, the evidence collectors and the drift checks ship as source in your own environment. We sit with whoever owns the assessment during the first cycle, so the narrative is defended by people who understand the system rather than read about it.
What we build
Four stages, and the reason each one is worth automating.
Scope discovery in code
Static and runtime analysis over repositories, logs, queues and integrations to find every place a primary account number is read, written, forwarded or accidentally retained. This is the part done badly everywhere, because a workshop finds the flows people remember and misses the ones written three years ago. Output is a data-flow map with a file and a line behind every node.
Control mapping and gaps
What you run today, mapped against the requirements, split three ways: satisfied, missing, and satisfied but undocumented. The third category is the one that costs a cycle, because the control exists and the assessor cannot see it. Each gap carries the change that closes it and whether it is a code change, a config change or a policy.
Evidence that stays current
Configuration snapshots, access reviews, key rotation records, scan results and change approvals collected on a schedule rather than assembled in the weeks before an assessment. Each artefact is stamped with what produced it and when, so the pack is a record rather than a reconstruction.
Drift monitoring
Compliance is a state on the day of the audit and a decay curve afterwards. A new service starts logging a full card number, a firewall rule is widened for a release, a role grant outlives the person. Checks run against the mapped controls and raise the change that broke one, with the commit or the ticket attached.
Scope out of the code, not out of a workshop
The data-flow map is generated from your repositories and traffic, so the systems in scope are the ones that actually touch card data, including the ones nobody remembered.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
We shrink the scope, not just the checklist
An assessor tells you whether you pass. An engineering partner changes what is being assessed. Moving card capture to hosted fields or a client-side token request takes your servers out of the cardholder data environment, and the cheapest control is the one you no longer need.
Evidence built by the system that runs
Evidence assembled by hand before an audit is stale by the next one. Collectors that run on a schedule inside your environment mean the second cycle costs a fraction of the first, and the answer to a question about a specific date exists without an archaeology project.
The certification stays where it belongs
We do not issue attestations and we will not imply otherwise. The QSA or the acquirer signs, and we make sure what they are handed is complete, consistent and defensible by your own people.
Questions
Can you certify us?
No. A Level 1 assessment is signed by a Qualified Security Assessor, and self-assessment questionnaires are signed by you. We are the engineering vendor. What we do is reduce what falls in scope, close the gaps, and make the evidence something your assessor can work through quickly rather than reconstruct with you.
What does the AI actually do here?
Two jobs where the volume defeats people. It reads code, logs and integration surfaces to find card data flows, including the ones no interview surfaces, and it maps existing controls and artefacts to requirements so a human reviews a draft instead of starting from a blank matrix. Findings carry the file, line or config they came from, so every one of them can be checked. Nothing is asserted without a source.
How much scope can realistically be removed?
It depends on where card data is captured today, and we will not put a number on it before looking. The shape is predictable: if your own servers see a primary account number, the work is getting them out of that path; if they already do not, the work is proving it and keeping it true. The discovery stage tells you which of the two you are in within the first weeks.
We already passed last year. Why would we do this?
Because passing and staying passed are different problems. If last year's evidence was assembled by hand, this year starts from nothing again. The value is in the second cycle and every one after it.
Does this work alongside our QSA?
That is the intended shape. The assessor sets what has to be shown, we build the systems and the artefacts that show it. Doing discovery before the assessor arrives usually shortens the engagement, because the scope conversation starts from a map instead of a whiteboard.
Part of Fraud & Identity
Let genuine users through and hold fraud risk down, without turning onboarding into a wall.
Onboarding that converts,
controls that hold.
Where does risk cost you today: false declines, slow KYC, missed fraud? Tell us and we'll tune the system around it.