We just secured another PCI-DSS deal today, and once the customary celebration has died down, we will set aside time to start planning for the project. For this project, PKF works with our QSA (Qualified Security Assessor) vendor, Control Case, to ensure that our clients get the best consultation and services possible, and to almost guarantee a certification in PCI-DSS. I say almost guarantee, because there are no such thing as 100% in this world. For instance, what if a meteor crashes on earth just as the PCI-DSS audit was about to start? Sure, we’ll all go the way of the dinosaurs, but was our client certified? No!

Anyway, jokes aside, we’re gearing up for the new year, with PCI-DSS, some ISO27001 and our normal COBIT assurances in the pipeline. The reason why we focus so much on these 3 standards and framework (COBIT is NOT a standard!) is because they are inter-related. ISACA and other groups have mapped all three to each other in a sort of matrix fashion, so that sitting down with a PCI-DSS guy and talking about the 12 requirements, you inherently can map COBIT controls on those 12 requirements, and hey, presto, to the 11 domains of ISO27001. PCI-DSS can be mapped against ISO27001 as well, especially to the holy Annex A controls of the ISO standard. The fact is, anyone that has ISO 27001 experience will be interlaced with PCI-DSS and COBIT as well. They are all siblings of the same mother, IT governance and audit.

Of the 3, both PCI-DSS and COBIT has taken major steps forward. PCI-DSS 2.0 came out 2 years back and added in virtualisation and a lot more clarifications on testing procedures. The big step forward was that now risk assessment documentation must be verified against accepted risk management methodology. Before this, there wasn’t such a need. In doing so, PCI-DSS is moving closer to his bigger brother, ISO27001, which is risk-based.

COBIT has always been risk based. Anyone that comes at you with a COBIT checklist should be questioned. We’re not saying checklist is wrong, but there must be a context of that checklist. We see a lot of “checklist based on industry benchmarks.” That’s one way. But each business is different. Not every IT division needs a IT strategic roadmap with a 5 year plan on IT investments. I know one of my client whose IT guy is basically the guy from Low Yat, doesn’t. That client needs more controls on information leakage and policies governing that Low Yat guy. Fix what’s priority. Fix what is highest risk. And in order to do that, you need to know, interact, interview with the client.

COBIT 5 takes this literally. For too many years, practitioners has been throwing COBIT controls like fireworks on Chinese New Year Eve. Comply to this, else we will give you a big fat zero! We’ve been using COBIT 4.1 for a long time now, and it still remains an ‘auditor’s framework’. With COBIT 5, we move up the ranks to IT governance. It’s a different way to audit. Here we look at the causal relationships of IT and business. The controls tie to the governance of IT within the context of the organisation, hence putting practitioners with risk experience to the forefront. Unlike the haphazard way of trying to tie RISK IT, VAL IT and COBIT together, COBIT 5 hopes to bring in a more uniform approach to IT auditing, one that will hopefully transpose the audit from the realm of the IT techies to the board.

With COBIT 5, the checklist wielding junior internal auditor whose knowledge of IT consist of facebook and farmville will, hopefully, go the way of the dinosaur, and be replaced by practitioners who has real world experience, management insights and the technical-business acumen to bridge technology into corporate relevance.