Security Is a Product Decision: RTD's ISO 27001 and SOC 2 Journey

Fraud decisioning is a trust business before it is a scoring business. A bank can accept a slower vendor for a while; it cannot accept a vendor that treats access control, audit evidence, incident readiness, or customer data protection as paperwork to be solved later.

That is why Run-True Decision has started an active ISO 27001 and SOC 2 program with Vanta in June 2026. We are early in the journey, and the wording matters: RTD is working toward ISO 27001 certification and SOC 2 readiness. We are not claiming certification, an audit pass, regulator approval, customer approval, or a promised completion date. What we can say publicly is that both frameworks are active in our Vanta program and evidence work is underway.

The reason to share this now is not to collect a badge ahead of the work. It is to make our operating philosophy visible: security, compliance discipline, and customer-data protection are day-one product priorities for the Fraud Decision Engine, not a checklist we plan to bolt on after scale.

Why this matters to banks and fintechs

Financial institutions buy fraud systems under pressure, but vendor trust is still earned through evidence. The buyer needs to know how sensitive data is protected, who can change the system, what gets logged, and how the vendor proves control operation over time.

ISO/IEC 27001:2022 provides a structured way to manage an information security management system. SOC 2 is an AICPA attestation framework where an independent CPA firm examines a service organization’s controls over areas such as security, availability, confidentiality, processing integrity, and privacy. Those frameworks matter in bank and fintech due diligence because they turn security intent into evidence: policies, control owners, access reviews, asset inventories, vendor oversight, change management, incident response, and monitoring records.

For a fraud platform, the bar is especially high. The system may touch transaction metadata, device and session signals, decision outcomes, analyst actions, and audit trails. Even when a deployment is designed for data residency or on-premise operation, the vendor still has to show disciplined engineering and support practices. A bank cannot outsource accountability to a certificate, but it can use certification work to test whether a vendor knows how to run a controlled environment.

Why Vanta now

The best time to build evidence habits is while the company is still small enough for habits to become architecture. Starting now lets us design controls into daily engineering work instead of reconstructing them during a late procurement review.

Vanta helps us organize the work in one operating loop: map framework requirements, assign owners, collect evidence, monitor control health, and make gaps visible. That does not replace judgment, and it does not turn a young company into a mature program overnight. It does give us a live system of record for the work that should already be happening: access reviews, secure development practices, device and account hygiene, vendor reviews, policy acknowledgement, risk tracking, and incident preparation.

For a founder/operator, that matters because the first version of a control is rarely perfect. The important question is whether the organization can see the gap, assign the owner, fix the process, and keep evidence that the fix is real. That is the muscle we want before larger customer environments depend on it.

What RTD can safely say today

RTD has an active certification/readiness program underway; RTD does not yet claim ISO 27001 certification or a completed SOC 2 report. We will not use this announcement to imply a result that has not happened.

Here is the public-safe status:

• Active program: ISO 27001:2022 and SOC 2 work is active in Vanta.
• Evidence underway: control evidence is being collected, reviewed, and improved as part of normal operating work.
• No completion promise: we are not publishing a target audit date, guaranteed outcome, or certification date.
• No customer or regulator claim: this work is our responsibility; it is not an approval from a customer, auditor, regulator, or partner.

That restraint is intentional. In fraud and cybersecurity, overclaiming is itself a trust problem. A public security update should help customers understand posture and direction without asking them to infer more than the evidence supports.

Customer data protection is product work

Customer-data protection is not a separate back-office project; it is a set of product and engineering decisions repeated every week. The controls we care about most are the ones that shape how the Fraud Decision Engine is built, operated, changed, and investigated.

Examples include:

• Data minimization: collect and retain only what a fraud decision, investigation, or audit trail requires.
• Least privilege: make production and administrative access narrow, reviewed, and revocable.
• Secure SDLC: require code review, dependency awareness, testing, and change records before product behavior changes.
• Audit logging: record who changed rules, reviewed cases, exported evidence, or touched sensitive configuration.
• Incident readiness: prepare escalation paths, roles, and records before an incident forces improvisation.
• Vendor discipline: know which third parties are in the operating path and what risk each one introduces.

These practices are not glamorous, but they are the difference between a platform that merely processes alerts and one that can support governed fraud operations. They also connect directly to how we describe the RTD platform: explainable decisions, auditable workflows, and deployment patterns designed for institutions with strict data-protection expectations.

The anti-fraud connection

A fraud decision engine asks customers to trust decisions made under time pressure, so the engine itself must be trustworthy under scrutiny. The same discipline that makes a fraud decision defensible also makes a security program credible.

Fraud teams live in the space between speed and accountability. A payment may need a fast Accept, Step-up, Review, or Block decision; a supervisor may later need the reason codes, analyst actions, and evidence trail behind it. That is why we keep returning to decision auditability in our product thinking. The customer should not have to choose between operational speed and the ability to explain what happened.

The same principle applies to security and compliance operations. If an access review happens, it should leave evidence. If a production change ships, it should have an owner and a record. If a vendor is added, the risk should be visible. Trust is not a slogan; it is the accumulation of decisions that can be inspected later.

The founder/operator lesson

From a founder/operator perspective shaped by cybersecurity, fraud fighting, and Southeast Asian banking risk, one lesson is hard to ignore: controls that are not operated under real pressure do not protect customers when pressure arrives.

That is why this journey matters to RTD now. We are building for financial institutions that will ask hard questions, and they should. They will want to know how we protect customer data, how we govern changes, how we monitor access, how we prepare for incidents, and how our product produces evidence when a fraud decision is challenged.

ISO 27001 and SOC 2 work can help structure those answers, but the certificate or report is not the final goal. The goal is a company that treats security evidence as part of product quality; a team that fixes gaps while they are still small; and a Fraud Decision Engine that earns trust before it scales.

Run-True Decision is building a Fraud Decision Engine purpose-built for Southeast Asian banks, with security evidence and customer-data protection treated as product responsibilities from day one. Talk to us to learn more.