Compliance Built to Keep Pace with Financial Regulation

Aidas Iskauskas, Head of Compliance at Velmie, explains how the company operates its ISO/IEC 27001 information security management system and assesses additional regulatory requirements for specific clients, jurisdictions and services.

Technology governance has become a central part of financial-sector supervision. Regulators increasingly examine how institutions manage ICT risk, outsourced services, data, incidents and operational continuity. These requirements increasingly shape the security, resilience, contractual and evidence expectations placed on technology providers supporting regulated institutions.

Velmie’s compliance function is led by Aidas, Head of Compliance. His current remit centres on the company’s ISO/IEC 27001 information security management system, internal policies, control oversight, audits and the assessment of client-specific security and regulatory requirements. Velmie’s established foundation is ISO/IEC 27001; other regulatory frameworks are assessed according to the client, jurisdiction, and scope of the engagement.

The program is anchored in ISO/IEC 27001:2022, which specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system.

We spoke with Aidas about how this foundation operates across Velmie and how additional requirements can be evaluated when clients enter demanding regulatory environments.

What does your role cover at Velmie?

Aidas Iskauskas: As Head of Compliance, I oversee Velmie’s compliance and information security management framework, which is currently founded on our ISO/IEC 27001 information security management system.

My responsibilities include policies, risk assessments, control oversight, awareness, supplier reviews, audits and corrective actions. I coordinate with delivery, infrastructure, engineering, legal and management when an engagement introduces new security or regulatory requirements.

I ensure external commitments match what Velmie has implemented and can evidence. For requirements outside our current framework, I assess applicability, gaps, ownership, resources and management approval before commitment.

How does ISO/IEC 27001 influence the way Velmie operates?

Aidas: ISO/IEC 27001 is our current common foundation for information security. It connects risk assessment, control ownership, internal review and management accountability within a defined information security management system.

That structure matters because information security reaches well beyond infrastructure. It affects how employees join and leave the company, how access is approved and reviewed, how suppliers are assessed, how incidents are escalated and how information is handled during client delivery.

Control owners remain accountable for operating their controls. The Compliance function provides oversight and challenge, reviews the available evidence and monitors whether identified weaknesses are addressed.

The standard also requires continual improvement, so we review the system as Velmie changes rather than treating the controls agreed during the last audit as permanently adequate. At the same time, ISO/IEC 27001 certification applies to a defined scope; it should not be presented as proof of compliance with DORA or any other sector- or jurisdiction-specific regulation.

How do you prevent policies from becoming a documentation exercise?

Aidas: A policy has value only when it changes how decisions are made. For access management, I expect to see why access was requested, who approved it and whether it remains appropriate. For incident management, the record should show how the event was assessed, who was informed and what was changed afterwards. Supplier oversight should provide a clear view of the service, the associated risk and the controls agreed with the provider.

Those records should be produced through normal operations and be available when an auditor or client requests them. If evidence has to be reconstructed afterwards, that can indicate that the requirement has not yet been fully integrated into the process.

We also pay attention to exceptions. A policy cannot anticipate every operational situation, particularly in a technology organisation. An exception may be justified, but it should have a documented rationale, an authorised risk owner, appropriate compensating controls where necessary, formal approval and an expiry or review date. Otherwise, a temporary workaround can gradually become the real process.

What do MiCA and DORA mean for Velmie’s European client engagements?

Aidas: MiCA and DORA have brought governance and operational resilience closer to the centre of regulatory supervision. MiCA establishes requirements for crypto-asset service providers, including governance, internal controls, business continuity and ICT arrangements.

DORA establishes detailed requirements for in-scope financial entities, including authorised crypto-asset service providers, covering ICT risk management, incident management, resilience testing and ICT third-party risk. Its effect on a technology provider depends on the provider’s role, the services delivered, contractual commitments and whether any direct provider obligations apply.

Velmie does not assume that every MiCA or DORA requirement is already implemented across the company. When these requirements are relevant to a client, we assess the elements within our scope against existing controls, identify gaps and agree any necessary changes, evidence and contractual responsibilities before committing to them.

The regulated institution remains accountable to its regulator. Velmie’s responsibility is to operate the controls within our agreed scope and provide the evidence needed for those controls. Where material changes are required, they need a realistic implementation plan and appropriate ownership, time and resources.

How does the approach change across priority markets such as the GCC and Africa?

Aidas: There is no single GCC or African compliance framework. The applicable requirements depend on the country, regulator, client’s legal entity, licence, regulated activity, service model and whether the arrangement is treated as outsourcing or another form of third-party service.

In the GCC, for example, a Saudi institution may assess cybersecurity against relevant SAMA requirements; a UAE bank may apply CBUAE outsourcing requirements; and a Qatari institution may refer to QCB requirements for technology risk, cybersecurity, cloud services or data handling. These examples describe client-side regulatory contexts, not certifications currently held by Velmie.

Africa is equally diverse, so the specific country, regulator and type of financial institution need to be identified before a commitment is made. We can then compare the applicable requirements with our ISO/IEC 27001 baseline, clarify responsibilities and determine the controls, evidence, timetable and resources required for that engagement.

Does supporting several jurisdictions require a separate compliance program for each market?

Aidas: Not necessarily. Velmie uses its ISO/IEC 27001 information security management system as a common baseline rather than claiming to maintain a fully implemented internal program for every jurisdiction in advance. For a specific opportunity or engagement, the applicable requirements should be mapped against that baseline.

The mapping should distinguish what is already covered, what remains the client’s responsibility and what would require a new Velmie control, technical configuration, process or contractual measure. Existing access-management controls, for example, may support several evidence requirements, while a client or regulator may still prescribe additional review periods, notification timelines or conditions for cloud use, data location and subcontracting.

Control mapping does not mean that different frameworks are equivalent, and ISO/IEC 27001 certification should not be interpreted as demonstrating compliance with a sector-specific regulation. Additional obligations are incorporated into an engagement only after their scope, ownership and delivery requirements have been assessed and agreed.

When should Compliance become involved in a client program?

Aidas: Compliance should ideally be involved while the solution and operating model are still being defined. I view this as compliance by design: decisions about hosting, data flows, administrative access and subcontractors can have regulatory consequences, and changing them after implementation may be expensive and disruptive.

Incident management is a good example. If a contract specifies that Velmie must notify the client within a particular period, we need to confirm before accepting the commitment that the operating process can detect, classify, escalate and communicate the relevant event through agreed contacts. Contractual wording alone does not create that capability.

The review starts with the client’s applicable requirements and the proposed delivery scope. We then separate existing organisational controls from client-owned obligations and project-specific controls. Any gap that requires a new capability needs to be assessed and planned; it should not be assumed to exist simply because it appears in a proposal or policy.

What happens when a new requirement appears during a long-running engagement?

Aidas: The first step is to confirm whether the requirement applies, to whom it applies and from when. Banking platforms may remain in service for many years, but regulatory interpretation and accountability depend on the client’s legal and compliance functions and, where necessary, specialist advice.

When a client identifies a new applicable obligation, or Velmie identifies a relevant change within its own scope, the appropriate response is a structured impact and gap assessment. This should distinguish existing controls, configuration or contractual changes, new internal processes and responsibilities that remain with the client.

Where a change is required, an owner, priority, evidence requirement, timeline and necessary budget or resources should be agreed. Implementing a substantial new framework can take many months and may require additional specialist capacity, so it should not be promised without a proper assessment and management decision.

Where the change can be integrated into the existing information security management system, we update the relevant control at source. Where it represents a broader transformation, it should be managed as a separate initiative with appropriate governance. This keeps the approach sustainable and transparent.

Which additional standards and governance frameworks may become relevant to financial technology providers?

Aidas: Business continuity and artificial intelligence governance are likely to become increasingly important, but their relevance depends on the services actually provided and the requirements of the target clients and markets.

ISO 22301 is an established management-system standard for business continuity. Velmie can use it as a reference or consider formal adoption if a defined business or client need justifies it, but it is not part of Velmie’s current certification scope.

ISO/IEC 42001 provides a management-system approach to the responsible development and use of artificial intelligence. For AI use cases connected with the European market, the organisation’s role and obligations under the EU AI Act may also need to be assessed. Neither framework should be presented as implemented across Velmie solely because AI tools are used.

We evaluate additional standards and frameworks against real operational and client needs. Formal adoption or certification would require a gap assessment, a management decision, a defined scope, owners, resources, implementation evidence and ongoing operation. Adoption should follow a clear need rather than be treated as a documentation exercise.

How do audits and client assessments contribute to Velmie’s current program?

Aidas: Internal and external ISO/IEC 27001 audits test the information security management system from different perspectives. They may show that a control is not being applied consistently or that documentation no longer reflects the way a process operates. A client assessment may also identify an evidence or control requirement arising from a particular licence, jurisdiction or service.

We examine the underlying cause rather than responding to every finding with another document. The appropriate response may involve ownership, training, system configuration or a change to the process itself. We also verify the effectiveness of remediation, because closing an action is not the same as demonstrating that the underlying risk has been addressed.

Client due diligence is particularly useful because financial institutions assess technology risk through their own regulatory responsibilities. A credible response distinguishes what exists today, what remains client-owned, what can be implemented for the engagement and what requires a separate decision and implementation plan.

What does this practical compliance model mean for Velmie’s clients?

Aidas: It means that their requirements are assessed against a real, operating ISO/IEC 27001 foundation rather than assumed to be covered by broad compliance claims.

Velmie can provide evidence of controls within its current operational and certification scope. For a new engagement, the applicable licence, jurisdiction and service requirements can then be identified, and any gaps and responsibilities can be agreed.

This supports transparent due diligence and realistic delivery planning. If additional controls, processes or certifications are required, Velmie and the client can agree feasibility, ownership, timeframe and resources before a commitment is made.

Financial technology and regulation will continue to evolve. Our management approach is designed to respond systematically, while ensuring that new capabilities are implemented in a controlled, evidenced way and aligned with real client needs.