ISO 27K Without the Bloat: An Open Source Approach

It’s often framed as an enterprise-only exercise: long timelines, expensive tooling, consultants everywhere, and a lot of compliance work that exists mainly to survive an audit. As a ~40-person, engineering-driven SaaS company, we needed the same level of trust and rigor as much larger organizations — but we weren’t willing to accept shelfware, parallel compliance infrastructure, or controls that only exist on paper.

We also didn’t stop at ISO 27001.

We now hold ISO 27017 (cloud security) and ISO 27018 (data privacy for cloud service providers). Those extensions matter, because we’re both a cloud service provider and a cloud customer, and we sit directly in the path of sensitive customer telemetry.

So the question we optimized for was simple:

The answer turned out to be: Yes.

We went from kickoff in August to certification in December, with a new security lead hire, a senior engineering org, and minimal net-new tooling. We didn’t build a separate “compliance stack.” We tightened the systems we already run in production and treated them as first-class security controls.

This post isn’t about how we wrote policies. It’s about how the controls actually work.

Starting From a Real Baseline

When the security function was formalized at Bindplane, we weren’t starting from zero. Bindplane already had a SOC 2 Type II compliant posture, mature CI/CD pipelines, and engineers who were used to guardrails, automation, and operational ownership.

Joining a mature, primarily senior, engineering organization as a security manager is hard. Everyone is extremely bright, understands their responsibilities clearly, and the hardest part, have been doing things this way for a really long time.

That mattered, because ISO didn’t require us to rethink our security model. It required us to formalize it, close gaps where controls were implicit or weakly enforced, and dramatically improve evidence quality — especially around endpoints and cloud responsibilities.

Two things made a compressed timeline realistic.

First, the majority of controls already existed in practice and were operationally enforced. Build pipelines, access control, vulnerability scanning — these were real systems, not aspirations. ISO was mostly about tightening and mapping, not re-inventing.

Second, we’re a small, senior organization. Change management is radically easier when you’re not coordinating across dozens of teams and thousands of endpoints. Swapping tooling or enforcing new baselines is uncomfortable, but it’s doable — and fast.

The Rule That Shaped Everything

This became a foundational principle for the entire project:

GRC Frameworks are intentionally vague. That vagueness can be used to design strong systems — or do just enough to act like you did.

Our internal filter for every requirement was simple and unforgiving:

• Can this control be enforced by a system, not a checklist?
• Can we produce evidence on demand, without assembling screenshots?
• Does this still make us safer if no auditor ever asks about it?

If the answer was no, we redesigned the implementation:

That mindset is what kept this from turning into compliance theater.

Open Source First, by Default

Most ISO requirements were already covered by the stack we run every day: Kubernetes, OpenTelemetry, Prometheus, Terraform, CI pipelines, and open-source vulnerability scanning.

The work wasn’t buying more tools. It was recognizing that these systems already were controls — we just needed to treat them that way and tighten enforcement where it mattered.

Paid tools only entered the picture when enforcement was more important than flexibility. Endpoints were the clearest example of that.

Why MDM Was the One Decision That Really Mattered

Endpoints were the highest-risk gap relative to ISO expectations. That’s where we focused our spend.

We evaluated Open Source offerings for MDM. There were some great options out there, but when we evaluated the risk, impact of compromising a self hosted MDM service, and time to implement, hosting this ourselves didn’t make sense. Then, we evaluated IRU (prev. Kandji).

IRU gave us three things that mattered more than feature depth:

• A fast path to a hardened baseline using CIS Benchmarks for macOS.
• Centralized, uniform enforcement with predictable user impact.
• Evidence by default — configuration state is queryable, not anecdotal.

We imported our existing SOC 2 MDM profiles directly into Kandji, staged the rollout, and accepted the expected (and manageable) user complaints. Within days, endpoint posture moved from informal best-effort to consistently enforced and audit-defensible.

Without this change, the ISO timeline simply wouldn’t have held.

Malware and Malicious Domains: No Hand-Waving

Malware protection and malicious domain access controls are where a lot of ISO programs quietly fall apart. There are many different options to meet this control - Antivirus, EDR, MDR, XDR - TL;DR we needed something we could trust. It needs to be deployed automatically and enforce DNS policies across a fully remote workforce.

We implemented centrally enforced network-level protections through managed endpoint controls. The tool choice matters less than the evidence model.

This control is centrally enforced, continuously applied, and observable over time, with defined exception handling and audit trails. During audits, we don’t explain how it should work. We show dashboards, test pages, and weekly reports. No screenshots of static configs. No “trust us” narratives.

CI/CD as a Security Control, Not a Suggestion

Endpoint security alone isn’t enough. Our CI/CD pipeline is part of our ISO story by design.

Every release passes multiple vulnerability scans. We continuously scan production and historical builds so newly disclosed CVEs don’t silently invalidate older releases. Security checks aren’t advisory and they’re not manual — they’re enforced in the release path.

Open-source tools like Trivy do most of the work here. The value comes from where the checks live, not how expensive they are.

ISO 27017 and 27018: Where the Real Work Starts

Internally, we maintain a living Governance Risk, and Compliance (GRC) control matrix that maps each ISO clause and Annex A/SOC 2 Type 2 control to the enforcing system, the evidence source, and the operational owner.

That document acts as a gap detector, not just a compliance artifact, and it translates cleanly across frameworks. Responsibilities are clear, controls enforcement is automated and transparent.

Once you think about ISO this way, it stops being intimidating and starts looking like a design problem.

ISO 27001 is the baseline. ISO 27017 and ISO 27018 are where things get uncomfortable — and more honest.

ISO 27017 focuses on cloud security responsibilities. It forces clarity around the shared responsibility model: what we’re responsible for as a SaaS provider, what our cloud provider is responsible for, and where those boundaries actually sit in practice.

That matters because we’re both a cloud service provider and a cloud customer.

27017 pushes beyond generic controls and into cloud-specific reality:

• How secure configuration is enforced in multi-tenant systems
• How cloud infrastructure risks are handled, not just acknowledged
• How responsibility boundaries are documented and enforced

ISO 27018 goes further, focusing on data privacy for cloud service providers. This isn’t about writing a privacy policy — it’s about operational guarantees around how customer data is accessed, processed, retained, and protected by default.

For us, these certifications mattered because they align directly with how Bindplane is built and operated. We handle customer telemetry. We operate shared infrastructure. We sit directly in the data path.

From a security perspective, 27017 and 27018 forced sharper decisions. From an audit perspective, they removed ambiguity. Instead of explaining how generic controls might apply to SaaS, we could point to controls designed specifically for cloud providers.

Dogfooding Our Own Platform as Evidence

We don’t just secure Bindplane — we operate Bindplane using Bindplane, alongside independent audit and compliance validation.

Telemetry from services, infrastructure, and databases flows through OpenTelemetry and Prometheus into our own pipelines. We use that data operationally, but it also gives us a longitudinal evidence trail for system behavior, availability, and change impact.

This is one of those things that sounds nice in theory and turns out to be invaluable in practice.

Cost, Timeline, and What Actually Matters

We did work with auditors and limited consultants — that’s inherent to ISO. The difference is where we avoided unnecessary spend: overlapping security tools, compliance platforms, and parallel evidence systems.

What made this work was a solid SOC 2 baseline, a small and senior engineering org, and low-friction change management. Those don’t eliminate the work, but they compress timelines dramatically.

The lesson isn’t that ISO is easy. It’s that it doesn’t have to be bloated.

For customers, this isn’t about logos on a trust page.

It’s about knowing that the systems handling your data are secured by real controls, not policies written for auditors. That endpoint security is enforced. That cloud responsibilities are explicit. That privacy isn’t abstract.

ISO 27001 establishes the baseline. ISO 27017 and 27018 show that the baseline actually holds up in a cloud-native, SaaS reality.

Final Thoughts

ISO 27001 isn’t hard because the controls are complex. It’s hard because teams try to implement it around their systems instead of through them.

If your controls are real, enforced, and observable, ISO becomes an exercise in mapping — not theater.

This control model has continued to hold as our systems, data surface area, and customer expectations have scaled.

And that’s achievable in months, not years, without lighting a massive tooling budget on fire.