This article recommends using SOC2 compliant vendors. I wouldn't put faith an a SOC2 certificate. A vendor who's infrastructure consists of almost entirely of hardware and software that's been EoL for years (and wasn't up-to-date before support expired) can pass SOC2, so long as they show that their firewall does NAT for security.<p>Okay, I'm being somewhat hyperbolic, NAT for security is not the only box a company has to tick to get a SOC2 cert. But I'm being less hyperbolic about long-EoL kit passing SOC2 audits. IMO, a vendor running unsupport(-ed|-able) kit should be an immediate disqualifier.
<i>> The security risk to bank account details is regionally specific. In Europe, IBAN and BIC numbers are readily given out. One reason why is that they are only used in the credit direction.</i><p>That's not true, IBANs can be used for direct debit between supporting banks. That's most commonly used for repeat invoices but some shops also support it as payment option for one-time purchases, although instant payments are taking over the latter use-case.
Quarterly vuln scans don’t really make the cut in the modern world. Take CVE-2020-1350 (MS DNS vuln) as an example - it took about 48 hrs from publicizing the vuln to a working exploit to appear on Github.<p>If you scan per quarter, and it takes you n days or weeks (or months) to fix the critical stuff, it’s quite a window of exposure - per each vuln. Any midsize org will carry hundreds or thousands. Enterprises much more.
Audits and compliance only take you so far. If your actual motivations are to truly improve security, perhaps offering code samples, libraries and reference architectures would be more helpful. Throwing compliance requirements at a technical team is an excellent way to distract them away from a truly secure architecture.<p>That said, there are a lot of actors out there who need babysitting and absolutely should not be allowed to participate in payment networks without some sort of initial & ongoing due diligence.<p>This whole thing is a delicate balancing act, but in my experience dealing with PCI-DSS, its currently an extremely heavy-handed approach. I cannot help but wonder if the primary intent of this sort of standard isn't to just keep competitors out.
The NACHA response is missing the forest for the trees. Securing the account data is great, but it's only a small piece of the puzzle.<p>It doesn't:
a) penalize ACH Originators responsible for submitting the fraudulent entry (beyond the recently implemented $4.50 charge)
b) do anything to promote alternative account numbers for EFTs, which in theory could be better protected as they won't be on paper checks
c) promote better validation tools to prevent the likes of Plaid and entities using their APIs from harvesting broad amounts of private consumer financial data