Blog · Essay · security audit that cut critical vulnerabilities
What It Took to Run a Security Audit That Cut Critical Vulnerabilities by 90% at SettleSavvy
When I read the headline “CEOs have had enough of incremental AI” in a recent CIO article (source I paused. The piece is a reminder that CEOs can no longer treat AI or security as after‑thoughts. At SettleSavvy, a fintech that had just rolled out a new AI‑driven settlement engine, the reality was harsher: a full‑blown security audit exposed dozens of critical vulnerabilities that could have derailed the product launch.
In this post I walk through the exact things that broke, the audit process we ran, the fixes that delivered a 90 % reduction in critical findings, and the concrete actions any CEO can take on Monday to avoid a repeat.
1. The trigger – why the audit became non‑negotiable
SettleSavvy had secured a $15 M Series B round and was preparing for a regulatory sandbox in Singapore. The regulator required proof of ISO 27001 compliance before allowing the AI engine to process live transactions. The compliance team, which had been focused on data privacy check‑lists, suddenly faced a full security audit covering:
- Asset inventory and classification
- Threat modelling for the AI pipeline
- Access‑control review across cloud and on‑premise components
- Penetration testing of the settlement API
The deadline was 45 days – a timeline that would have forced a rushed, superficial audit or a costly re‑submission. The stakes were clear: fail the audit and the product launch would be delayed, eroding investor confidence and giving competitors a window to capture market share.
2. What broke before the audit
2.1 Fragmented ownership of security controls
Security responsibilities were scattered across three teams: the AI engineers owned model‑training environments, the DevOps squad managed the Kubernetes cluster, and the compliance group handled data‑privacy policies. No single owner could answer, *“What is the current risk posture of the settlement API?”* This diffusion caused blind spots.
2.2 Legacy components without documented hardening
Two legacy micro‑services – the legacy ledger and the reconciliation engine – still ran on outdated Docker images (Ubuntu 16.04). Their Dockerfiles lacked the latest security patches, and the team had no inventory of the libraries they pulled in.
2.3 Over‑privileged service accounts
Service‑to‑service authentication relied on static API keys stored in plain‑text configuration files. An internal audit later showed that 12 of the 15 keys granted admin‑level access to the database, far beyond what the services needed.
2.4 Incomplete logging and monitoring
While the AI engine emitted rich telemetry, the surrounding orchestration layer logged only error‑level events. When a penetration test triggered a series of failed login attempts, the security team had no timeline to correlate the activity.
3. The audit process – step‑by‑step execution
3.1 Assemble a cross‑functional audit squad
I convened a 30‑person war‑room: two ISO 27001 lead auditors (myself and a colleague), the CISO, the AI lead, the DevOps manager, and a senior compliance analyst. We defined a RACI matrix for each audit domain and set daily stand‑ups to keep momentum.
3.2 Build an immutable asset inventory
Using an automated discovery tool, we generated a CMDB (Configuration Management Database) that listed every host, container, and third‑party SaaS service. Each asset received a classification tag (e.g., *high‑value‑transaction*, *support‑tool*). This inventory became the single source of truth for the rest of the audit.
3.3 Conduct threat modelling on the AI pipeline
We ran a STRIDE session focused on the settlement API, data‑ingestion queues, and model‑serving endpoints. The outcome was a set of attack trees that highlighted the most likely paths an attacker could take to tamper with transaction data.
3.4 Perform targeted penetration testing
Instead of a blanket pen‑test, we scoped three scenarios derived from the threat model:
- API abuse – trying to bypass rate limits and inject malformed settlement requests.
- Container escape – exploiting known CVEs in the legacy Docker images.
- Credential stuffing – using the over‑privileged service keys to gain database access.
Each scenario produced a report with severity ratings aligned to ISO 27001 Annex A controls.
3.5 Map findings to remediation owners
Every critical finding was logged in a Jira board with fields for *owner*, *due date*, and *verification steps*. Owners were accountable for delivering a fix and a proof‑of‑concept demonstration before the next audit checkpoint.
4. Fixes that delivered a 90 % reduction in critical findings
4.1 Centralise identity and access management (IAM)
We migrated all service accounts to Azure AD Managed Identities. Each micro‑service now receives a short‑lived token scoped only to the resources it needs. This eliminated the 12 over‑privileged keys and reduced the attack surface dramatically.
4.2 Harden legacy containers
All legacy Docker images were rebuilt on Ubuntu 22.04 LTS, with security patches applied and unnecessary packages removed. We introduced Docker Content Trust to enforce signed images in the CI/CD pipeline.
4.3 Implement least‑privilege RBAC across the AI pipeline
Using OPA (Open Policy Agent), we codified policies that enforce read‑only access for model‑training jobs and write‑only access for the settlement API. The policies are version‑controlled alongside the codebase, ensuring auditability.
4.4 Upgrade logging and SIEM integration
We deployed Elastic Stack with a unified logging schema. All services now emit structured logs at *info* level, and alerts are routed to a Splunk‑based SIEM that correlates events across the AI engine, the orchestration layer, and the database.
4.5 Conduct a rapid re‑audit of critical controls
After implementing the fixes, we ran a focused re‑audit on the 12 original critical findings. Ten were closed outright, and the remaining two were downgraded to *moderate* after additional mitigations. The final audit report showed a 90 % drop in critical vulnerabilities.
5. What CEOs must inspect on Monday
| Action | Owner | Why it matters |
|---|---|---|
| Verify the CMDB is up‑to‑date | CTO | Guarantees you know every asset that could be in scope for regulators |
| Review IAM policies for service accounts | CISO | Prevents the “static key” nightmare that almost derailed SettleSavvy |
| Confirm that all containers are built from approved base images | DevOps Lead | Stops legacy vulnerabilities from resurfacing |
| Walk through the latest SIEM alert dashboard | Security Analyst | Early detection of anomalous activity before it becomes a breach |
| Schedule a 30‑minute executive debrief on audit findings | CEO | Keeps the board informed and aligns remediation with business timelines |
If any of these items are missing, flag them immediately. The cost of a missed control is far higher than the effort to validate it.
6. Lessons for other CEOs
- Treat the audit as a product launch milestone, not a checkbox. Align the audit timeline with your go‑to‑market plan.
- Assign single‑point ownership for each audit domain. Diffused responsibility leads to blind spots.
- Automate inventory and policy enforcement. Manual spreadsheets cannot keep pace with micro‑service churn.
- Prioritise remediation that reduces risk exposure rather than ticking boxes. The 90 % reduction came from fixing high‑impact items first.
- Communicate the audit outcomes to the board in plain language. Executives need to understand risk in business terms, not just control numbers.
FAQ
How long does a full ISO 27001 audit typically take for a mid‑size fintech?
A focused audit can be completed in 4‑6 weeks if you have an up‑to‑date asset inventory and clear ownership of controls. Extending the timeline usually reflects gaps in documentation or fragmented responsibilities.
Can we skip the re‑audit after fixing critical findings?
No. A rapid re‑audit validates that fixes are effective and that no new critical issues have been introduced. It also satisfies regulators who often request evidence of remediation.
What if our legacy code cannot be rebuilt on a modern OS?
Consider container isolation: run the legacy code in a hardened VM with network segmentation, and restrict its access to only the data it needs. This mitigates the risk while you plan a longer‑term rewrite.
Does moving to managed identities increase latency for service‑to‑service calls?
The impact is negligible (typically <5 ms) and is outweighed by the security benefits of eliminating static credentials.
How often should we refresh our CMDB?
At a minimum quarterly, but ideally after every major release or infrastructure change. Automated discovery tools can keep it current with minimal overhead.
If you’re wondering how these steps translate to your own organisation, let’s talk. I’m happy to walk through a discovery call and map the audit‑ready checklist to your roadmap.
Book a conversation or explore more on the Rohan Girdhani homepage.
Related reads
In the market
Headlines this post is responding to — not invented stats.