The Breaking Point
It was 11 PM on a Tuesday in Toronto when Hunter Zhu closed the laptop lid a little harder than he should have.
He had spent the past six hours, after a full workday, trying to configure a well-known GRC platform for a client. The client was a 30-person SaaS company that needed SOC 2 certification to close an enterprise deal. It should have been straightforward. The company had a clean AWS environment, a small engineering team that already followed reasonable security practices, and a CEO who was willing to do whatever it took.
But nothing about the tool was straightforward.
The platform had generated over 180 controls, many of which had nothing to do with the client’s reality. Physical security badge access policies, for a fully remote company. Server hardening procedures, for a serverless architecture. Multi-environment segregation workflows, for a startup running a single production account. And for every irrelevant control, there was a form to fill out, an exception to document, or a justification to write explaining why it didn’t apply.
Hunter had been in the compliance and cybersecurity world long enough to know what good security looked like. Since 2003, he had helped many organizations build information security management systems, navigate complex audits, and design controls that genuinely protected their operations. He knew that compliance, done right, was supposed to make organizations stronger, not bury them in busywork.
But that night, staring at a dashboard full of green checkmarks that represented work no one had actually done and controls no one truly understood, he couldn’t shake a single thought:
“The tool is the problem.”
Hunter ZhuToronto, 11 PM on a Tuesday
Four Frustrations That Changed Everything
Hunter’s frustration wasn’t born from a single bad evening. It was the culmination of years spent watching the same patterns play out across dozens of client engagements, each one reinforcing the same set of systemic failures in the tools the industry had come to rely on.
The Complexity Trap
The tool meant to reduce the compliance burden needed its own compliance project.
Every GRC platform Hunter worked with sold itself on simplicity. “Connect your cloud accounts and be audit-ready in weeks.” The marketing was slick. The reality was something else entirely.
These platforms were built around a dense web of interdependent concepts (frameworks, controls, tests, evidence, policies, risk registers, vendor management modules) all wired together in ways that demanded not just compliance expertise, but deep familiarity with the platform’s own internal logic. Change one control and watch the cascade: linked tests break, evidence requirements shift, framework mappings go stale.
Hunter watched this play out again and again. A mid-market healthcare company spent four months just deploying a GRC tool, longer than it would have taken to achieve the certification itself. A fintech startup hired a full-time analyst whose entire job became managing the compliance platform, not managing compliance. A growing company lost its only compliance-trained employee, and with her went every piece of institutional knowledge about how their GRC tool was configured, because the configurations were so complex that no one else on the team could decipher them.
The learning curve wasn’t a speed bump. It was a wall. And for companies without dedicated compliance teams, which was most of the companies Hunter worked with, it was often insurmountable.
“I kept asking myself: why does the tool that’s supposed to reduce the compliance burden require its own compliance project to get running?”
Hunter ZhuOn the complexity trap
The Black Box
A compliance tool that is not itself auditable.
The second frustration cut deeper, because it touched the integrity of the compliance process itself.
Every platform Hunter used presented compliance status through polished dashboards: percentage readiness scores, pass/fail indicators, color-coded risk matrices. The numbers looked precise. The visualizations looked authoritative. But when Hunter dug beneath the surface, he found that neither he nor his clients could answer basic questions:
- How was this control derived from the framework requirement?
- Why was this particular test chosen as evidence of effectiveness?
- What logic determines whether this control is “passing” or “failing”?
The answers were locked inside the vendor’s proprietary system. The organization was told it was 87% ready for SOC 2, but it couldn’t independently verify what that number meant. It couldn’t explain its compliance posture to an auditor in its own words. It couldn’t even determine whether the controls the platform had generated were the right controls for its specific environment.
Hunter remembered one audit where the external auditor asked a client’s CEO to walk through a specific control: how it was designed, how it was implemented, how they knew it was working. The CEO looked at the dashboard, then looked at the auditor, and said: “The tool says it’s green.”
That was the moment Hunter understood the depth of the problem. These platforms weren’t helping organizations own their compliance posture. They were creating a dependency, a black box that organizations paid for but never truly understood.
“There’s a deep irony in using a compliance tool that is itself not transparent or auditable. These frameworks exist so organizations can demonstrate how their controls work, not just that they exist.”
Hunter ZhuOn the black box
The Busywork Tax
Weeks spent documenting why controls did not apply.
The third frustration was the most visible to the people on the ground: the engineers, the IT managers, the operations leads who were asked to interact with these platforms.
GRC tools were built to serve a broad market. A 15-person startup and a 5,000-person enterprise got fundamentally the same control sets, the same policy templates, the same workflows. The platform didn’t ask about the company’s size, its architecture, its regulatory landscape, or its operational reality. It simply applied its pre-built model and expected the organization to adapt.
Hunter had a client: a small data analytics firm, fully cloud-native, no customer-facing application, no physical offices. The GRC platform generated controls for physical security, application penetration testing, on-premise server management, and multi-site disaster recovery. None of these applied. But each one required the client to formally document why it didn’t apply, write a justification, mark it as “not applicable,” and sometimes write a compensating control statement just to satisfy the platform’s workflow.
The team spent weeks on this, weeks that should have been spent on the controls that actually mattered for their environment. The engineering lead started calling the GRC platform “the homework machine.” The CEO started questioning whether the certification was worth pursuing at all.
And the cost wasn’t just measured in hours. It was measured in trust. When engineering teams were asked to implement controls that didn’t match their architecture, they lost faith in the compliance function. When practitioners were forced to do work they knew was meaningless, they disengaged. The tool that was supposed to make compliance painless became a source of organizational friction, and cynicism.
“These companies are doing more work because of the compliance tool than they would have done without it. We’re not reducing the burden, we’re adding to it.”
Hunter ZhuOn the busywork tax
The Rigidity Problem
Configuration debt, compounding silently.
The fourth frustration was the slowest to emerge but, in many ways, the most damaging.
Organizations change. They acquire companies, enter new markets, adopt new technologies, restructure teams, migrate cloud providers, spin off business units. A compliance program that can’t adapt to these changes isn’t a program. It’s a snapshot.
Hunter watched a client go through a technology migration, moving from a single-cloud AWS setup to a multi-cloud environment with Azure. The moment the migration began, the GRC platform fell apart. Integrations broke. Evidence collection stopped. Controls that had been “passing” for months suddenly showed as “failing”, not because security had degraded, but because the platform’s monitoring assumptions no longer matched reality.
Fixing it wasn’t a quick reconfiguration. It was a multi-week project that required re-mapping controls, re-building integrations, re-collecting evidence, and re-verifying everything the platform had previously validated.
Hunter started calling this “configuration debt”, the growing gap between the platform’s state and the organization’s actual state. Like technical debt, it compounded silently. The dashboard kept showing numbers, but the numbers increasingly represented a historical reality, not the current one.
The Decision
It wasn’t a dramatic moment. There was no single incident, no boardroom epiphany, no midnight revelation. It was a gradual accumulation of evidence, engagement after engagement, client after client, that led Hunter Zhu to a quiet but absolute conviction:
The conviction
The compliance industry didn’t need another GRC platform. It needed a fundamentally different approach.
The existing tools were optimized for a specific outcome: passing an audit. They valued comprehensiveness over relevance, evidence collection over control effectiveness, checkbox completion over genuine risk reduction.
Hunter didn’t want to build a better version of the same thing. He wanted to rethink the problem from first principles.
And so, from a home office in Toronto, Nank AI Inc. was born.
Building the Opposite
Every design decision at Nank.ai traces back to one of the four frustrations. Not abstractly, directly. Hunter didn’t write a mission statement and hope the product would follow. He wrote down the specific failures he had witnessed, and he built the antidote to each one.
Against Complexity: Compliance as a Service
The biggest insight wasn’t about technology. It was about people.
Hunter realized that the complexity problem was, at its root, a misallocation of responsibility. GRC platforms handed organizations a powerful but opaque machine and said: “Here, you figure it out.” For companies without dedicated compliance teams, which was exactly the companies that needed the most help, this was an impossible ask.
Nank.ai’s answer was Compliance as a Service. Not just a platform, but a platform paired with a dedicated compliance manager who owns the work end-to-end. The compliance manager coordinates everything: policies, risk assessments, evidence collection, auditor communication. The client’s team only touches the parts their day-to-day work requires: approving an access review, confirming a control, uploading a piece of evidence.
“Most of our customers come to us because hiring a full security and compliance team is slow and expensive. We act as that team, augmented by AI.”
Hunter ZhuOn Compliance as a Service
Against the Black Box: Transparency by Default
When Hunter designed Nank.ai’s platform, he started with a rule: every control must be traceable.
The platform maintains a shared control library that maps each control to the framework requirements it satisfies: ISO 27001, SOC 2, HIPAA, PIPEDA, GDPR, PCI DSS, NIST CSF, and more. Write a control once, see exactly which clauses it addresses, across every framework.
What determines whether a control is “passing”? The platform shows the evidence, the test logic, and the result, not just the color. No proprietary scoring algorithms. No unexplainable percentages.
“If you can’t explain your compliance posture without opening the vendor’s dashboard, you don’t have a compliance posture. You have a subscription.”
Hunter ZhuOn transparency
Against Busywork: Context-Aware Controls
Nank.ai doesn’t start with a generic control set and ask the organization to carve out exceptions. It starts with the organization.
The process begins with a gap assessment, typically completed within the first two weeks, that maps the company’s actual environment. From that assessment, the compliance manager and the platform derive a tailored control set that reflects the company’s reality, not a hypothetical average.
And because Nank.ai supports twelve frameworks from one control library, organizations pursuing multiple certifications don’t duplicate work. A single control maps to every framework it satisfies. The work is done once.
“We had a client ask us, ‘Where are the 60 controls I’m supposed to mark as not applicable?’ We told them there aren’t any. Every control in your program exists because it’s relevant to your environment.”
Hunter ZhuOn context-aware controls
Against Rigidity: Living Compliance
Nank.ai was built to evolve with the organization, not against it.
The platform provides continuous monitoring, always-on control checks that catch drift the moment it happens, not during a frantic pre-audit scramble. The compliance score reflects the organization’s state today, not the state it was in when someone last bothered to update the configuration.
“Compliance isn’t a point-in-time event. It’s a living system. If your tool can’t keep up with your organization, it’s already failing you.”
Hunter ZhuOn living compliance
What Nank.ai Is Today
From that Toronto home office, Nank AI has grown into a company trusted by security and compliance teams at organizations including law firms, digital health companies, agencies, nonprofits, electronics recyclers, and maintenance software providers.
The platform supports these frameworks from a single control library:
Most customers reach audit readiness in about three months. The dedicated compliance manager stays with the client through the audit and beyond, not just to pass the test, but to build a compliance capability that endures.
The CaaS model, platform plus human expertise augmented by AI, isn’t a compromise. It’s the entire thesis. Hunter built Nank.ai on the belief that compliance is too important to automate away and too complex to leave to a self-service tool. It requires understanding: of the framework, of the organization, and of the gap between the two.
The Lesson
If there’s a single lesson in the Nank.ai story, it’s this:
The lesson
The best products don’t come from market analysis. They come from pain.
Hunter Zhu didn’t start Nank.ai because he saw a gap in a market map. He started it because he spent years watching compliance tools create the very problems they claimed to solve, and he couldn’t accept it anymore.
Every feature in the platform, every design choice, every organizational decision traces back to a specific moment where something broke: a client buried in irrelevant controls, an auditor met with a blank stare, a dashboard showing green while the real compliance posture quietly deteriorated.
Those moments didn’t just motivate the company. They are the company. They’re encoded in its architecture, its service model, and its values.
And they’re the reason that when a new client signs up and asks, “So how does this actually work?”, the answer isn’t “Here’s your login, good luck.”
The answer is: “Let us show you. Your compliance manager will take it from here.”
Compliance without the homework machine
Nank.ai runs SOC 2 and ISO 27001 programmes for Canadian companies from Toronto, with a dedicated compliance manager and your data held in Canada. Every control in your program is there because it applies to you.