A 0–1 playbook
for fintech security.

FramingWhy a methodology matters.

Most organizations approach security reactively. Something breaks, someone panics, a vendor gets hired, a report gets filed, and things go quiet until the next incident. This pattern is expensive, stressful, and most importantly, doesn't reduce risk over time. The organization ends up patching individual holes without ever understanding the shape of the thing it's trying to protect.

A methodological approach changes that. It provides a repeatable process for understanding an attack surface, identifying what matters most, and making deliberate decisions about where to invest limited security resources. It turns security from a series of fire drills into a program that can be reasoned about, communicated to stakeholders, and improved over time.

FrameworkThe OODA loop as a security framework.

The methodology presented here borrows its structure from John Boyd's OODA loop, a decision-making framework originally developed for military strategy that has since found application in business, competitive strategy, and, as it turns out, information security. OODA stands for Observe, Orient, Decide, Act. It describes a cycle: gather information about the environment, make sense of it in context, choose a course of action, execute, and then start the cycle again with updated information. The steps map naturally to organizational security.

This framework is effective because it provides structure, and because attackers operate the same way. A competent adversary will observe an organization's external footprint, orient around what's valuable and reachable, decide on an attack path, and execute.

Most organizations, when they engage with security at all, are stuck somewhere in Observe. Many never get past Orient. Almost none complete the full cycle repeatedly. The goal of this methodology is to move through the entire loop, learn from each pass, and build a security posture that improves continuously rather than decaying between incidents.

01ObserveIntelligence gathering.

The first step is building an honest picture of the current state. It's not possible to protect what isn't visible, and most organizations have gaps in their own understanding of the attack surface they need to manage. This phase is about assembling that picture from the outside in, and the inside out.

The external footprint

The starting point is what an attacker would see. External reconnaissance is the first step any adversary takes when evaluating a target, and for a moderately sized company, it typically takes less than an afternoon to get a usable picture of the exposed surface.

External footprinting covers four surfaces:

• DNS and subdomains. The full extent of internet-facing infrastructure, including what may have been forgotten: staging environments left running, internal tools exposed to the public internet, leftover infrastructure from defunct projects.
• Exposed services. Open ports, admin panels, database interfaces, development tools reachable from the internet. All potential entry points.
• Cloud resources. Storage buckets, serverless endpoints, container registries that may be misconfigured or unintentionally public.
• Public information leakage. Job postings, open-source repos, social media, technical blog posts. These reveal tech stacks, internal tooling, infrastructure patterns, and even the security team's size (or its absence) to an attacker doing their homework.

The tools for this work are freely available. Shodan and Censys index internet-facing infrastructure and support searching for specific assets of organizations. Subfinder and Amass automate subdomain discovery. Certificate transparency logs at crt.sh show every TLS certificate ever issued for a given domain. Attackers use all of these, so defenders should use them first.

Internal asset inventory

External footprinting reveals what the world can see. Internal inventory reveals what actually exists. These two pictures are different, and the gap between them is the space that attackers attempt to occupy.

An internal asset inventory should cover services and their relationships. It maps what components make up the system, what talks to what, and where sensitive data flows between them. It should enumerate third-party integrations, which are every external service the system depends on, from KYC providers to banking APIs to analytics services. Each integration is a trust relationship with security implications. It should include software dependencies. Lastly, it should document who can reach what, through which interfaces, and at what privilege level.

While an asset inventory may seem daunting, it doesn't need to be formalized in a CMDB or an enterprise asset management platform. For a small to medium-sized business, a well-maintained spreadsheet or internal wiki page is a perfectly valid starting point. What matters is that the inventory exists and that someone owns keeping it up to date.

One category of assets that consistently escapes inventory efforts is personal accounts used for business operations. It's common, especially in early-stage companies, for infrastructure to end up registered under a founder's personal email or individual account. This could be a Cloudflare account managing production DNS, an Apple Developer account tied to a personal Apple ID that publishes the company's mobile app, or a domain registrar login known only to one person. These accounts are invisible to any automated inventory process because they exist outside the organization's identity boundary. They often lack MFA, aren't subject to access reviews, and represent single points of failure: if the account holder leaves, loses access, or gets personally compromised, the business-critical resource goes with them.

Existing protection mechanisms

While mapping assets, it's worth documenting what protections are already in place. The goal is to complete the picture. Notable examples are: TLS configuration, rate limiting, WAF or DDoS protection, logging and monitoring, access-control policies, secrets-management approach, MFA enforcement, and incident-response procedures.

02OrientThreat modeling and contextualization.

Observation produces raw information. Orientation provides meaning based on that information. In this phase, the inventory from the previous step gets examined through three questions: What needs protecting? Who might attack it? And where are the gaps between the current posture and the actual risk?

Critical asset identification

Not all assets are created equal, and not all breaches are equally damaging. A defacement of a marketing website is embarrassing. A breach of customer funds is existential. Orientation starts with identifying critical assets and ranking them by the impact of their compromise.

For a fintech or payments company, critical assets typically fall into a few categories:

• Customer funds held in custody or banking relationships.
• Cryptographic keys that control access to wallets or authorize transactions.
• Customer identity data, including KYC documents, personal information, and transaction histories.
• Partner and banking credentials, such as API keys and access tokens for fiat rails.
• Operational infrastructure, providing the ability to process transactions and serve customers.

Each of these has a different value to an attacker and a different impact on the business if compromised. Funds and keys are directly monetizable. Identity data can be sold, used for further fraud, or leveraged for extortion. Partner credentials could enable unauthorized transactions through banking relationships. And operational disruption, most commonly through ransomware, can be used as an extortion lever even if no data is actually exfiltrated.

Ranking these forces is a conversation that many organizations avoid: does the security investment actually reflect the stated priorities? If the most critical asset is the private keys controlling $12M in customer funds, but the majority of security effort has gone into hardening the web application, there's a misalignment worth examining.

Threat modeling

Threat modeling fundamentally means understanding who might attack, why, and how. Not every organization faces the same threats. A DeFi protocol with $700M in smart-contract TVL and a fiat-to-crypto payments company with $12M in custody face very different adversary profiles, even though both operate in the cryptocurrency space. Realistic adversary categories for a fintech company typically include:

• Financially motivated criminal groups. Organized operations that target companies for direct monetary gain, including state-sponsored groups like Lazarus that fund national programs through crypto theft.
• Opportunistic attackers. Individuals or groups scanning the internet for low-hanging fruit, running known exploits against unpatched services, and moving on if the initial effort doesn't pay off.
• Insiders. Current or former employees, contractors, or support staff who have or had legitimate access and might misuse it, whether through malice, coercion, or carelessness.
• Supply-chain compromise. Attacks that reach a target indirectly by compromising a vendor, library, or tool in the dependency chain.

The point of the threat modeling exercise is to be realistic about who the likely adversaries are, so that security investments are proportionate. Over-indexing on nation-state threats when the most likely attacker is an opportunistic adversary running default Shodan queries leads to spending money on the wrong things.

Mapping the gaps

With assets ranked and adversaries identified, the next step is mapping the gap between what exists and what's needed. For each critical asset: what controls are currently in place? Given the identified adversaries, are those controls sufficient? Where are the most obvious weaknesses?

This exercise produces a list of gaps ranked by the criticality of the asset they affect and the realism of the threat they're exposed to. It doesn't need to be exhaustive to be useful. Even identifying the top five gaps gives a concrete starting point.

03DecidePrioritized vulnerability assessment.

With observation and orientation complete, the picture is clear: what needs protecting, who might attack it, and where the gaps are. The Decide phase turns that understanding into a prioritized action plan. This phase is about building a triage system that feeds clean, prioritized results to the people who need to act on them, rather than adding yet another source of noise. It starts with leadership defining strategic areas of focus based on the Orient output, and those focus areas then motivate the engineer to run targeted, specialized assessments rather than broad sweeps.

Prioritization is based on impact, likelihood, and exploitability. A critical vulnerability in the custody integration, which could be exploited by a known adversary using freely available tools, is fixed before a theoretical weakness in a system that holds no sensitive data is addressed. Not everything needs fixing. What matters is fixing the right things first.

Reviewing the code

With the strategic focus areas defined, code review narrows to the components that matter most. For Volta, that means the custody integration code, the admin panel, and the CI/CD pipeline configuration. It's important to underline that this should never entail the entire codebase.

For organizations without a dedicated security team, automated tooling is the most practical starting point. Static analysis tools like Semgrep or CodeQL scan source code for known vulnerability patterns such as SQL injection, cross-site scripting, insecure cryptographic usage, and hardcoded secrets. They're not perfect, and they produce false positives, but they catch the class of issues that are most embarrassing to miss. Dependency auditing tools like npm audit, pip-audit, Dependabot, and Snyk check the dependency tree against databases of known vulnerabilities. The key with automated tools is fine-tuning. Running a scanner with default rules against a large codebase produces a report full of noise. Running it with rules tuned to the relevant stack and risk profile produces findings worth acting on. The difference between the two is usually a few hours of configuration.

Reviewing the infrastructure

The infrastructure review focuses on the environment in which the code runs, scoped to the same strategic focus areas. For Volta, that means focusing on the CI/CD pipeline configuration and the cloud infrastructure supporting custody and admin-panel operations, rather than conducting a comprehensive audit of every AWS service in use.

Tools like Prowler automate configuration checks for AWS environments. Scoped to the relevant services and run with findings filtered to high and critical severity, they often produce actionable output without much time commitment.

Reviewing internal processes

Technical controls only work if the processes around them hold up. A perfectly configured secrets vault doesn't help if the onboarding process gives every new hire access to every secret. A well-designed access-control system doesn't help if offboarding consistently forgets to revoke access.

Key processes to examine:

• Incident-response readiness. Is there a documented plan for what to do when something goes wrong? Has anyone rehearsed it? Who gets called, and who makes decisions?
• Key management. Who holds cryptographic keys, how are signing ceremonies structured, what's the recovery process, and what's the bus factor?
• Access-control hygiene. Is the principle of least privilege applied in practice? Are access reviews happening regularly? Are credentials rotated regularly?
• Security awareness. Do employees handling sensitive data or customer interactions know what phishing and spear-phishing look like? Is there a process for reporting suspicious messages? Has the organization communicated baseline expectations around credential handling and social engineering?

Thoughts on prioritization

When this phase is complete, findings from the code, infrastructure, and process reviews will be on the table. Some will be quick fixes, others will require architectural changes. The temptation is to fix the easy things first because it feels productive.

Prioritization should be based on an issue's impact on critical assets. If the asset ranking from the Orient phase puts custody access at rank 1, then the shared API key across environments and the lack of monitoring on custody API calls should be at the top of the remediation list, even if the SQL injection in the admin panel is technically easier to fix.

04ActRemediation and hardening.

The Act phase is where findings get fixed. This sounds straightforward, and for individual issues it often is. But at the organizational level, remediation can be difficult. One reason for that is findings competing with product roadmap priorities for engineering time. A lack of clear ownership of security issues, coordination across teams or with external providers, and the risk of downtime or issues when touching production infrastructure are other significant reasons. It's important that any obstacles are considered and acknowledged upfront.

Remediation

Remediation should follow the priority order established in the Decide phase. For each finding, the approach is: understand the fix, test it in a non-production environment, deploy it, and verify it worked.

For code-level issues, remediation can be covered by the existing development workflows. Security fixes go through the same code review and deployment process as feature work, ideally with a clear label or tag so they're visible in sprint planning and don't quietly lose priority.

For infrastructure issues, the process is similar, but the blast radius of mistakes is larger. Configuration changes to IAM policies, network rules, or secrets management should be tested carefully. An overly aggressive IAM policy change can break production in ways that are difficult to diagnose quickly.

Hardening

Remediation addresses specific findings. Hardening is the broader work of making systems more resilient to classes of attacks, not just individual vulnerabilities. After the immediate fixes are in place, the patterns they revealed point toward architectural improvements that prevent entire categories of issues from recurring.

Detection

After addressing the known findings, investment in detection capability pays for itself. Monitoring, alerting, and logging aren't ends in themselves but fundamental components of an observation layer for the next OODA cycle. At a minimum, an organization should know when someone accesses a system they don't normally access, when authentication patterns change (e.g., unusual login times, locations, or frequency), when critical configuration changes occur in the cloud environment, and when unexpected outbound connections appear from the infrastructure. A SIEM or a SOC isn't necessary to achieve this. CloudWatch alerts, application-level logging, and a Slack channel that receives security-relevant notifications provide more visibility than having nothing.

The continuous loop

Security isn't a project with a completion date. It's a recurring process. Organizations evolve, and so does the threat landscape. Every assessment has a shelf life.

Each cycle through the OODA methodology should produce:

• An updated asset inventory reflecting new services, integrations, and dependencies.
• A revised threat model accounting for changes in the threat landscape.
• New findings from re-running assessment tools and reviewing recently changed code and infrastructure.
• Validated fixes confirming that previous remediation actually worked and hasn't regressed.
• Adjusted priorities reflecting the current state of risk.

How often the full cycle runs depends on how quickly the environment changes and how much effort and budget are warranted by an organization's risk profile. For a company like Volta, a quarterly full assessment with monthly lightweight checks (re-running automated scans, reviewing access lists, checking monitoring dashboards) is a reasonable starting cadence.

LimitsWhen to bring in external help.

This methodology is designed to be actionable without deep security expertise. A technically strong engineer with some curiosity and dedicated time can meaningfully improve an organization's security posture by working through these steps. But there are limits to what internal efforts can achieve, and it's worth being explicit about where those limits are.

The ideal engagement point is after completing at least one full cycle of this methodology. The environment will be understood, priorities will be clear, and the engagement with external assessors will be as informed partners rather than passive recipients of a report.

CloseSummary.

The methodology presented in this document isn't novel. It doesn't require proprietary tools, expensive platforms, or specialized knowledge to get started. What it requires is structure, honesty about the current state, and the discipline to follow through.

That's the point. Security isn't a destination. It's the loop.