Dfns Secures $16M Series A Funding – See the Full Announcement

Security

Dfns Certified ISO 27001, ISO 27017 and ISO 27018 by KPMG and MSECB

Thibault de Lachèze-Murel
Thibault de Lachèze-Murel
August 20, 2025
Read time:

Dfns achieves ISO 27001, 27017 and 27018 certifications, raising the bar on security, cloud assurance, and data privacy.

We’re proud to share that Dfns has earned ISO/IEC 27001, ISO/IEC 27017, and ISO/IEC 27018 certifications. The program was audited by KPMG, with certification issued by MSECB, an accredited certification body. These add to our SOC 2 Type I and Type II reports, which we have completed and renewed, and together they form a broader, deeper assurance story for clients who rely on Dfns for secure, programmable wallet infrastructure.

What ISO requires that SOC 2 doesn’t spell out

SOC 2 evaluates the design (Type I) and operating effectiveness (Type II) of controls against the Trust Services Criteria over a defined period. It’s powerful evidence that the controls we say we run are actually running and producing the intended outcomes. ISO/IEC 27001 (2022) asks for more than effective point controls: it requires a living Information Security Management System (ISMS) including governance, risk, resources, policy, metrics, audits, and continual improvement that tie security to business objectives. And ISO/IEC 27017 and 27018 extend this with cloud-specific security and PII privacy obligations that SOC 2 does not explicitly prescribe. 

ISO 27001 starts earlier and higher in the stack. It asks us to understand our context and stakeholders, define the scope of our security program, and run it as a system that is planned, resourced, measured, and improved. It also requires a formal approach to threat intelligence. We must identify sources, collect and triage signals on a defined cadence, and feed what we learn into vulnerability management and incident workflows. ISO expects a clear acceptable use policy for information and assets, not just implied good practice. It also asks for a specific framework for how we select and use cloud services, including shared responsibility, configuration, and ongoing assurance. Finally, ISO requires forensic readiness. We must plan how logs and other artifacts will be preserved, how chain of custody will be maintained, and how evidence will be used during investigations. These elements go beyond what SOC 2 calls for and make investigations faster and more defensible. Examples:

  • Threat intelligence as a formal practice: ISO requires us to formally collect, analyze, and use threat intelligence. SOC 2 checks that risks are assessed and monitored, but it doesn’t require a defined threat intel process. For Dfns, this means setting clear sources, frequency, triage steps, and ways to feed intel into our vulnerability and incident workflows.
  • Clear rules for acceptable use: ISO calls for explicit rules on how staff can use systems and data. SOC 2 implies this through general controls, but ISO requires a documented policy tied to onboarding, training, and enforcement.
  • Cloud security and shared responsibility: ISO adds a dedicated control for cloud services. It requires clarity on shared responsibility, provider selection, and ongoing assurance. SOC 2 tests outcomes in the cloud but doesn’t require a specific “cloud use” framework.
  • Forensic readiness and evidence collection: ISO requires us to plan how we preserve logs, artifacts, and chain-of-custody so incidents can be investigated and defended. SOC 2 checks logging, but ISO demands an explicit evidence strategy.
  • Technology readiness for business continuity: ISO requires continuity planning to cover technology details such as RTO/RPO targets, failover, backups, and recovery rehearsals. SOC 2 covers availability broadly, while ISO enforces detailed, tech-driven continuity planning.

Remote vs. office work, physical security, and monitoring

Dfns was founded in 2020 during the Covid pandemic, which shaped us as a remote-first company. ISO frameworks fit well with how modern teams operate, requiring specific controls for remote and hybrid work: secure endpoints, home office risks, split tunneling rules, screen privacy, and network posture checks.

SOC 2 verifies that access and change controls work regardless of location. ISO goes further, asking us to design and document a dedicated remote-work framework. It also raises the bar on security culture. We now spell out screening, terms of employment, training, device enrollment, discipline, and post-termination steps. SOC 2 touches these areas, but ISO makes them role-based and backed by proof of effectiveness over time.

Even as a remote-first company, we still maintain offices worldwide. SOC 2 checks that physical access controls exist and work, but ISO requires more. Physical security isn’t just locks and badges, it also means continuous monitoring of facilities. It covers supporting utilities like power, HVAC, and other environmental factors that affect availability and integrity. These risks apply even with cloud or colocation providers, since the ISMS must show how we select, contract, and oversee them.

Additional technical controls where ISO is more explicit

ISO provides a concrete catalog of technical controls and asks for explicit design and proof. Source code access must be governed with approvals, logging, and segregation. Capacity must be forecast and monitored so security does not degrade under load. Configuration management needs baselines, hardened images, and controlled drift. ISO also calls out information deletion, data masking in non production, and data loss prevention as named protections with chosen methods and verifiable processes.

Monitoring is not only about having logs. ISO asks for defined monitoring objectives and synchronized time across systems so events correlate during investigations. Powerful administrative tools are treated as a special risk that must be restricted and monitored. Web filtering is required to lower malware and exfiltration risk. Cryptography must follow a documented policy that covers approved algorithms, key lengths, key generation and storage, rotation, archival, and destruction, with roles and responsibilities clearly assigned. Secure coding practices must be defined and taught, and audit or test activity must be controlled so it does not disrupt production or leak sensitive data. These expectations line up well with how Dfns builds software and runs infrastructure, and they add clarity for client due diligence.

ISO 27001 is also a dense, practical catalog of technological controls:

  • Access to source code: ISO requires strict rules for who can read or change code, with approvals, logging, and separation of duties. SOC 2 checks that change controls work, but ISO asks for written policies and evidence.
  • Capacity management: ISO expects us to plan and monitor capacity to avoid outages or slowdowns. SOC 2 looks at uptime; ISO turns it into a measurable, proactive process.
  • Configuration management: ISO demands hardened baselines, controlled changes, and regular reviews. SOC 2 checks that changes are authorized; ISO requires formal baselines and audits.
  • Data controls: ISO explicitly calls out secure deletion, data masking, and data loss prevention (DLP). SOC 2 expects confidentiality, but ISO requires defined methods, tools, and proof these processes work.
  • Monitoring and clock sync: ISO requires clear monitoring objectives and synchronized clocks across systems so logs line up in investigations. SOC 2 checks logging; ISO adds structure and time discipline.
  • Privileged tools: ISO singles out admin utilities as a risk. We must restrict, monitor, and justify their use. SOC 2 expects least privilege, but ISO emphasizes these tools directly.
  • Web filtering: ISO requires control of outbound web traffic to block malware and prevent data leaks. SOC 2 doesn’t cover this explicitly.
  • Cryptography: ISO requires a documented crypto policy: approved algorithms, key sizes, lifecycle (generation, storage, rotation, destruction), and assigned roles. This matches Dfns’ key-management, MPC, and BYO-key practices, helping customers assess crypto posture quickly.
  • Secure coding and audits: ISO requires defined secure coding standards, developer training, and safeguards so audits and penetration tests don’t harm production or leak data. SOC 2 checks SDLC outcomes; ISO requires explicit rules and protections.

Cloud-specific additions from ISO/IEC 27017

ISO 27017 is written for cloud. The framework clarifies who does what in shared responsibility models, how we segregate customer environments in multitenant platforms, and how we review and change supplier services over time. It asks us to design for cloud risk and then keep that design current with evidence. In real terms, this means Dfns documents which controls sit with us and which sit with our cloud providers, how we select and monitor those providers, how we enforce network segregation, and how we verify that virtualized components remain isolated as we scale. SOC 2 will test that our controls worked, ISO 27017 requires we design for cloud risk and maintain that design with evidence.

Privacy protections from ISO/IEC 27018

ISO 27018 sets the standard for protecting personal data (PII) in the public cloud. It requires clear rules on how data can be used, bans secondary use without consent, ensures transparency for customers, and provides mechanisms for individuals to exercise their rights. It also mandates structured breach notifications and full auditability. While SOC 2 can cover privacy through optional criteria, ISO 27018 makes these obligations specific and detailed for cloud environments. It also complements GDPR by turning many of its principles, like purpose limitation, transparency, and data subject rights, into auditable controls. For clients, this means stronger guarantees on how personal data is handled across our platform and support processes backed by documented limits, logs, and notifications.

How this makes Dfns and our clients stronger

For Dfns, ISO turns good controls into a management system. Leadership commitment, policy and objectives, risk assessment and treatment, resources and competence, performance measurement, internal audit, management review, and corrective action and continual improvement create a closed loop. We are required to measure, review, and improve, not just maintain the status quo. SOC 2 Type II shows our controls operate effectively over time, but ISO shows the system that keeps them effective as threats and business needs change.

For our clients, the benefits are practical. Procurement is faster because ISO is globally recognized and mapped to regulations worldwide. Cloud assurance is clearer because ISO 27017 and 27018 make shared responsibility and privacy obligations explicit. Due diligence is easier because clause-level requirements translate directly into RFP answers, control walkthroughs, and audit artifacts, threat intel procedures, remote work standards, forensic readiness, cryptographic policy, configuration baselines, and ICT continuity. Regulators and risk teams see not just that controls exist, but that they are governed, resourced, measured, and improved within a recognized international framework.

Earning ISO/IEC 27001, 27017, and 27018 alongside renewed SOC 2 Type I and II is a milestone, not an endpoint. These certifications require ongoing internal audits, management reviews, corrective actions, and external surveillance audits. That cadence is by design and it keeps the bar moving up. 

If you’re evaluating wallet infrastructure for regulated or enterprise contexts and want to review our ISO certificates (or our SOC 2 reports), we can share them under NDA. More importantly, we’re happy to walk your teams through how the ISO clauses map to the controls you care about most so you can see exactly how this improves your security and trust posture with Dfns.

Authors