This is a bank Information Security and Cyber Risk view of quantum computing with a very specific lens: attacker economics, realistic exploit paths, and what we can do now that stays correct even if timelines move. This is not a prediction document.
Most companies want structure, but few want rigidity. When I started designing a workflow engine flexible enough to support assessments, issues, action plans, exceptions, vendor reviews, and policy changes, I realized one unavoidable truth: every business wants the freedom to configure a process their way, but they also need enough guardrails to keep approvals consistent and auditable. That tension-flexibility vs. structure, is exactly what a Unified Workflow System must solve.
One thing I underestimated when I first started building my GRC platform was the amount of flexibility people want when it comes to metadata. Everyone asks for “just a couple of extra fields,” and before you know it, you’re knee-deep in requirements around conditional logic, multi-model support, imports, exports, surveys, reporting, and tenant isolation.
Custom fields seem simple until you actually start designing them for a multi-tenant GRC environment. That’s when the fun begins.
Here are the real challenges I hit, and the approach that finally worked.
Over the past few weeks, I’ve been shaping the core structure behind Simple GRC — specifically how all the governance, risk, and compliance content connects together. I wanted something clean, logical, and scalable. GRC data tends to get messy fast — one framework references another, controls overlap, requirements duplicate, and every “simple mapping” turns into a web of dependencies.
To handle that without losing my mind, I built a model centered around Libraries, Objects, and Requirements. It sounds simple (and that’s the point), but there’s quite a bit going on under the hood.
Classifying data and applying proper handling is an important but somewhat complex task. On one hand, we have governance, which might be vague at best; on the other hand, we have operational teams trying to implement comprehensive handling mechanisms. In the middle, we have compliance reporting carried out by various teams trying to put everything together.
I’ve seen many instances when KRIs live their own life. Often, KRIs that are being showcased to the board are very operational. Like Number of DDos attacks. While the KRI presentation is not bad in itself, there should a value that drives this demonstration. What is a KRI, where they live, what they need to show, and who and when need to see them?
Some thoughts on NIST CSF (Cyber Security Framework) alignment.
What isn’t?
It is not a final solution. It is not controls framework.
What is CSF? It is a framework — strategic foundation or governance catalyst — a starting point that helps an organization structure its cybersecurity governance, risk management, and control implementation. You take the Framework and tailor it to your System.
What I’m describing here really applies to organizations that already have some level of maturity around their policies and standards.
If policies and standards exist but the overall program isn’t very mature, there are two possible paths. One — have a discussion about whether the organization understands the value and wants to invest in maturing the policy program. Or two — if there’s currently no appetite for that, take an honest look at what’s in place. Evaluate whether those policies actually create value.
If they don’t, it may make sense to simplify — keep a smaller, more focused set of documents that are actually used and kept up to date.
The main point is: if you’re going to have policies, do them well. Make sure they achieve their purpose and create value. Because policies that exist but aren’t followed just add overhead, weaken governance, and waste resources.