Engineer × CTO × CISO
Where Engineering meets governance
Compliance, audit, risk, legal, sales: eighteen years connecting engineering teams to the people who need to trust what they build.
Engineering: making requirements actionable. Equally at home hands-on or leading.
What I am passionate about
Delivery
End-to-end delivery of technology and compliance programmes, across the full range of stakeholders: engineering, product, compliance, enterprise risk, legal, audit, and the board. The DORA programme at PPRO is the clearest example of that breadth.
Data analytics
Testing control effectiveness across the full population catches outliers that hide inside an aggregate pass rate. More on this in the talk on auditing at scale.
Automation
Turning periodic, manual compliance checks into continuous ones makes evidence a byproduct of the engineering process, already there when the audit comes around. The DORA RoI Health Check is one example.
The full career history, including PPRO, ONPEX, and PAY.ON / ACI Worldwide, is on the About page. All talks, including the ones linked above, are on the Talks page.
DORA
DORA asks financial entities to prove operational resilience across five areas: risk management, incident reporting, resilience testing, third-party oversight, and information sharing.
ICT risk management
A documented resilience strategy sets the direction, then risk gets tracked through metrics that can be monitored continuously.
Incident reporting
A structured classification method, the right stakeholders pulled into decisions automatically, and the process itself tested regularly.
Resilience testing
Mapping failure modes for the product and the process both, then testing against them on a schedule.
Third-party oversight
Treated as a data problem: keeping the Register of Information current by connecting to the systems that already track vendors, like invoicing.
Information sharing
Exchanging threat and incident signal with partners and customers.
CRA
CRA's essential requirements (Annex I) are organised the way law is written: a list of clauses. Organised the way engineering is done, they cluster into six themes instead.
Secure by design and default
No known exploitable vulnerabilities at release, a secure default configuration that can be reset, minimised attack surface, and access controlled from the start.
Data and resilience
Confidentiality, integrity, and minimisation of the data processed, availability protected under stress including resilience against denial-of-service, and the impact of an incident reduced through mitigation built into the design.
Visibility and control
Internal activity monitored and logged. For the privacy-conscious: an opt-out. Unauthorised access reported, and users able to fully and securely remove their data.
Vulnerability management
A documented software bill of materials, remediation without delay, regular testing, and a coordinated, timely disclosure policy.
Keeping it updated
Updates distributed securely and without delay, with users notified and given the option to postpone.
Good neighbour
A product shouldn’t become the problem for someone else’s network: minimising its negative impact, or that of any connected device, on the availability of other devices and services.
PCI-DSS
PCI-DSS's structure already reads close to how engineering teams think. What experience adds is judgment: where the effort actually needs to go, and where the standard leaves room to spend less.
Minimise scope
The smaller the environment that touches real card data, the smaller the attack surface and the audit both. Tokenizing on entry is one way: operate on the token everywhere else, and reconstruct the real number only where it must reach an acquirer or another PSP.
Outsource what makes sense
Some requirements are cheaper to inherit than to build. Encryption key management is a good candidate: a cloud provider’s key management service can carry most of PCI-DSS’s key-management requirements on its own attestation, already assessed, already documented.
Automate the evidence, not just the control
Evidence that’s a side effect of the work itself carries more weight than evidence assembled specially for the auditor. A scheduled diff of firewall rules against the last approved baseline, flagging drift automatically, is one example: the record already exists when the assessment comes around.
Stay close to the SDLC
Problems are cheaper to fix the moment they happen than the week before an audit. Metrics on the SDLC itself, approvals completed, tickets documented, can surface deviations in real time.