TL;DR
Your first year of security is a time-boxed build project (gap analysis, policies, incident response, vendor risk register, DORA Register of Information), not an ongoing operations function. Plan it like a product launch.
After the build phase, ongoing security maintenance for a 30-100 person fintech runs 10-15 hours per week. That’s not a full-time CISO job.
Three options to close the function: full-time CISO, fractional/vCISO, or security engineer + compliance consultant. The right choice depends on your stage, not your ambition.
The most expensive mistake isn’t overpaying. It’s hiring someone who builds the wrong framework and you discover it during your first regulatory inspection.
EU regulators (Latvijas Banka, Bank of Lithuania) are prioritizing ICT governance, business continuity, and the DORA Register of Information in 2025-2026 supervision cycles. Know what they look for before they arrive.
You just got your EMI license. Or your PI authorization. Or maybe you closed a Series A and the term sheet had a line about “information security governance” that you nodded through at 2am.
Now it’s Tuesday morning and three things landed in your inbox. Your banking partner wants evidence of PCI DSS compliance before onboarding. An investor’s due diligence questionnaire asks about your incident response plan (you don’t have one). And someone from Latvijas Banka sent a politely worded letter about DORA reporting obligations with a deadline that’s closer than you thought.
All of this is sitting on your desk because you’re the CTO. And you’re already building the product.
I’ve been on the other side of this conversation about a dozen times in the past three years, usually sitting across from a CTO in Riga, Vilnius, or Warsaw who looks exactly like this. Smart, technical, stretched thin, and slightly panicking about a domain they didn’t sign up to own. This article is what I wish someone had handed them on day one.
The first year is a build project, not an operations role
Here’s the thing most CTOs get wrong: they think hiring for security means hiring someone to do security, day in, day out, forever. That’s not what year one looks like.
Year one of security in a 30-100 person fintech is a build project. It has a scope, deliverables, and a deadline. It looks like this:
Months 1-3: Gap analysis against your regulatory framework. For most EU fintechs right now, that means DORA (Regulation EU 2022/2554, fully applicable since January 17, 2025) and whatever your license conditions require. You map what exists, what’s missing, and what’s urgent. You also scope your PCI DSS cardholder data environment if you’re processing payments. PCI DSS 4.0.1 is now the only active version, and all future-dated requirements became mandatory on March 31, 2025. This isn’t optional if Visa or Mastercard is in your stack.
Months 3-6: Policy development. ICT risk management framework (DORA Articles 5-15, or Article 16 simplified framework if you qualify), incident response procedures, business continuity plan, access control policy, change management. For a company of 50 people, this is typically 12-18 documents. Not boilerplate downloaded from a template site, but policies that actually reflect how your engineering team works.
Months 6-9: Operational build-out. Incident response tabletop exercises. Vendor risk register populated with your actual third-party providers. DORA Register of Information (the structured register of all ICT third-party contractual arrangements) compiled and formatted for regulatory submission. Security awareness training rolled out. Vulnerability scanning operationalized.
Months 9-12: Testing and hardening. Internal audit of the framework. Penetration testing. Remediation of findings. Preparation for your first regulatory dialogue or supervision visit.
That’s the build phase. It’s intense. It’s 20-30 hours per week of dedicated security work, sometimes more during policy sprints.
And then it drops off a cliff.
After the build: maintenance mode is smaller than you think
Once the framework is standing, the ongoing work for a 30-100 person fintech looks different. I’ve tracked this across multiple engagements: 10-15 hours per week covers it for a company in this size range that isn’t experiencing active incidents or going through a major audit cycle.
That weekly cadence breaks down roughly like this: monitoring and alert triage (2-3 hours), policy reviews and updates triggered by changes in your tech stack or org (2-3 hours), vendor risk management for new or renewing contracts (2-3 hours), incident response coordination when something happens (variable, but usually 1-2 hours of non-incident coordination), and board/management reporting plus regulatory correspondence (2-3 hours).
This is not a full-time job. And that single fact should reshape how you think about your security hiring decision.
I’ve seen too many fintechs hire a full-time CISO at month one, pay them €120-180K per year, and then watch them run out of meaningful work by month eight. They start empire-building, requesting headcount, buying tools nobody needs, and turning a lean security function into a cost center that’s hard to unwind.
The most important question isn’t “should I hire a CISO?” It’s “how many hours per week does this function actually need right now?”
Three ways to close the security function
This isn’t a sales pitch for any one model. I’ve used all three, and each one has a place. Here’s when.
Option 1: Full-time CISO
When it fits: Your security operations consistently require 30+ hours per week, you’re processing high volumes of sensitive data, you have multiple regulatory frameworks in play simultaneously, and you’re large enough (typically 200+ people) that the CISO needs to manage a team, not just a program.
When it doesn’t: You’re a 40-100 person fintech in your first two years post-licensing. I’m not hedging here. I’ve seen this play out repeatedly, and the full-time CISO at this stage almost always leads to one of two outcomes: you overpay for the build phase and then have an expensive employee with not enough to do, or you hire someone junior enough to afford but too junior to build the framework correctly. Both are bad.
Cost reality: Full-time CISO compensation in Europe ranges from €100K to €200K+ depending on jurisdiction and experience. In the US, total compensation (salary, benefits, equity) averages $260K-$330K for companies under $200M revenue, according to the IANS Research 2025 compensation data. Add recruiting costs (20-25% of first-year salary) and you’re looking at a significant cash commitment before they’ve written a single policy.
Option 2: Fractional CISO / vCISO
When it fits: The build phase plus ongoing maintenance. A seasoned fractional CISO has done this build 5, 10, maybe 20 times across different companies. They know what Latvijas Banka asks for during ICT inspections because they’ve sat through those conversations before. They bring templates that have survived audits, not templates downloaded from an ISO 27001 vendor’s marketing page.
The economics: In Europe, vCISO retainers typically run €5,000-€15,000 per month depending on scope. In North America, hourly rates range from $200-$350. A build-phase engagement (heavy hours for 6-9 months) followed by a maintenance retainer (lighter hours) might total €80-120K for the full first year. That’s less than a full-time hire, and you get someone who starts delivering from week one because they’ve done this before.
What to watch for: Not all vCISOs are created equal. Some are former big-company CISOs who’ve never worked with a 50-person startup. Some are consultants who’ll hand you a gap analysis spreadsheet and disappear. The good ones stay accountable for the outcome: they’ll attend your regulatory meetings, own the DORA Register of Information, and pick up the phone when you have an incident at 11pm on a Saturday.
The downside nobody mentions: Availability. A fractional CISO is working with 3-5 clients. If two clients have incidents in the same week, you’re sharing their attention. Get this into the contract: SLA for response times, clearly defined hours, and escalation procedures.
Option 3: Security engineer + external compliance consultant
When it fits: You already have a strong internal engineer who’s technically capable, security-minded, and already handling some security work. What they lack isn’t technical skill but governance experience: how to write policies that satisfy a regulator, how to structure a risk register, how to prepare for a DORA supervision visit.
In this model, the engineer handles day-to-day security operations (vulnerability management, access reviews, incident triage) while an external compliance consultant builds the governance layer. The consultant comes in 2-3 days per month for framework design, policy review, and regulatory preparation. The engineer executes.
When it breaks down: If the engineer doesn’t have governance instincts and the consultant isn’t technically competent enough to understand your stack. I’ve seen this model produce beautiful policy documents that have no connection to how the company actually operates. The regulator will notice.
The Security Staffing Decision Matrix
Here’s a simple model I use with CTOs. It maps the key factors to the right staffing model for fintechs in their first two years:
If your honest answer is “we need 10-15 hours per week after the build phase,” a full-time CISO is the wrong hire. Period.
The most expensive mistake: hiring the wrong person
This one isn’t about money. It’s about time.
I worked with a Latvian EMI in 2024 that hired a security manager who’d spent 15 years in corporate IT at a telco. Good resume, real certifications, nice person. Six months later, they had an ISO 27001-style information security management system in place. Clean documentation. Proper control matrices.
One problem: the regulator didn’t ask for ISO 27001. They asked about DORA compliance. The DORA ICT risk management framework has specific requirements that ISO 27001 doesn’t cover: the Register of Information for third-party ICT providers (Article 28), specific incident classification and reporting timelines, digital operational resilience testing requirements, and the board accountability provisions. The security manager had built the wrong framework, and six months of work needed to be substantially reworked.
That’s the real cost. Not the salary. The rework, plus the missed regulatory deadline, plus the reputational damage of showing up to a supervision dialogue unprepared.
Four questions to screen a security hire (if you’re not a security expert yourself)
If you’re a CTO interviewing CISO candidates and you’re not a security specialist, these four questions will tell you whether someone understands fintech-specific security work:
1. “Walk me through how you’d build our DORA Register of Information. What data do you need, and where does it come from?”
Good answer: They describe identifying all ICT third-party service providers, mapping contractual arrangements, classifying which support critical or important functions, and structuring the data into the ITS template format for regulatory submission. They mention talking to procurement, engineering, and operations to build the inventory.
Red flag: They don’t know what the Register of Information is, or they conflate it with a generic vendor list.
2. “We process card payments. How would you scope our PCI DSS cardholder data environment, and where do you expect the boundaries to be?”
Good answer: They ask about your payment flow, tokenization strategy, and which systems touch cardholder data. They talk about reducing scope through segmentation and outsourcing card data storage to a PCI-compliant processor.
Red flag: They jump straight to “we need to be PCI DSS compliant” without asking about your architecture first. Scope is everything in PCI DSS, and bad scoping wastes months.
3. “If we had a ransomware incident at 3am on a Saturday, what’s the first hour look like?”
Good answer: They describe a concrete incident response sequence: containment, evidence preservation, internal notification chain, regulatory notification assessment (DORA requires initial notification within 4 hours of classifying a major ICT incident), and communication to affected parties. They mention not wiping systems before forensic imaging.
Red flag: They start with “call the police” or “notify the insurance company.” Those come later. The first hour is about containment and evidence.
4. “What does proportionality mean in the context of DORA implementation for a company our size?”
Good answer: They reference Article 4 of DORA, explain that requirements should be implemented in proportion to size, risk profile, and complexity of services. They give a concrete example: “A 50-person EMI doesn’t need a dedicated ICT risk control function the way a bank does, but it still needs documented ICT risk management.”
Red flag: They’ve never heard of proportionality in DORA, or they treat every requirement as equally weighted regardless of company size. This person will over-engineer everything and burn your budget on controls you don’t need.
What regulators actually look for (and where they find gaps)
I want to be specific here because “what does the regulator check?” is the question every CTO asks, and the answers they find online are usually just lists of DORA articles. That’s not useful. Here’s what actually happens.
Latvijas Banka (Latvia)
Latvijas Banka published its 2026 supervision priorities in January. The fintech-relevant focus areas are explicit: DORA compliance, ICT governance, outsourcing management, operational resilience, and business continuity. For 2026, they’ve planned 3 ICT-focused on-site inspections across the financial sector, plus 11 thematic off-site inspections and supervisory dialogues.
In practice, here’s what I’ve seen them focus on during supervision visits and dialogues with fintechs:
Register of Information. The first submission deadline was April 15, 2025 (with data as of March 31, 2025). Going forward, it’s annual by March 1 with data as of December 31. If your register is incomplete, poorly structured, or missing critical ICT providers, that’s the first finding. This is the single most visible compliance artifact because it’s submitted directly to the regulator.
ICT governance documentation. Do you have a documented ICT risk management framework? Does it match what you actually do? They’ll ask for the framework document and then ask your CTO or security lead to walk through it verbally. Mismatches between documentation and reality are a common finding.
Business continuity and incident response. Not just “do you have a plan” but “when did you last test it?” They want evidence of tabletop exercises, test results, and lessons learned. A business continuity plan that’s never been tested is a finding waiting to happen.
Outsourcing oversight. For fintechs that outsource heavily (and most do), they look at whether you’ve assessed the ICT risks of your outsourcing arrangements and whether your contracts include the mandatory DORA provisions (audit rights, exit strategies, sub-outsourcing controls).
Bank of Lithuania
Lithuania is one of the most fintech-dense jurisdictions in the EU. The Bank of Lithuania supervises hundreds of EMIs, PIs, and payment institutions. Their DORA supervision has been building since 2025, with particular attention to ICT risk management and outsourcing (a big deal in a market where many fintechs outsource development to third-party teams).
The pattern is similar: Register of Information compliance, ICT governance documentation, and incident reporting capability. But Lithuania also places heavy emphasis on AML/CFT alongside security, so expect supervision visits to cover both domains. If your security framework doesn’t address how security controls support AML transaction monitoring integrity, you’ve got a gap.
What they all have in common
Across Baltic and Central European regulators, the first supervision cycle post-DORA is focused on three things: do you have the framework documented, can you explain it, and have you submitted your Register of Information correctly? They’re not doing deep technical penetration testing of your systems. They’re checking governance. That’s both good news (it’s achievable) and a warning (you can’t fake it with a Confluence page labeled “Security Policy” that nobody reads).
What to do on Monday morning
If you’re a CTO reading this and recognizing yourself in the first paragraph, here’s the sequence:
This week: Decide which model you need (full-time, fractional, or engineer + consultant). Use the decision matrix above. Be honest about your hours-per-week number.
This month: If you don’t have a DORA Register of Information, that’s priority one. The next submission cycle will come whether you’re ready or not.
This quarter: Get your ICT risk management framework documented and reviewed. Not perfect, but documented. A regulator would rather see an honest framework with known gaps than a polished document that doesn’t match reality.
By month six: Run your first incident response tabletop exercise. Invite your CTO, operations lead, and whoever handles customer communications. Record the findings. Fix them.
Security in a post-licensing fintech isn’t mysterious. It’s a project with knowable deliverables, reasonable timelines, and a clear finish line for the build phase. The trick is treating it that way instead of either ignoring it or over-engineering it.
The CTOs who get this right aren’t the ones who hire the most expensive CISO. They’re the ones who correctly estimate the scope.
If you found this useful, share it with a CTO who just got licensed. And if you’ve been through this build phase yourself, I’d love to hear how your first year went. What surprised you? Reply or leave a comment.