Our methodology

Documentation-first, adoption-focused

We optimize for adoption, not just correctness. A policy that is technically right but never rolled out has not solved anything.

Most Kubernetes security work fails not because teams lack tools, but because they lack a usable operating model. We design that model.

Documentation-first

Every decision, recommendation, and finding is written down. We do not deliver verbal summaries or slide decks. We deliver documents — structured, reviewed, and ready for your team to act on.

Adoption-focused

We write for two audiences — leadership and engineers — and we do not conflate them. Every deliverable is scoped to its reader. Security standards your developers will actually follow, and summaries your managers can act on.

How an engagement runs

Each engagement follows the same four-phase structure. The scope varies by service — but the process does not.

1

Review

Days 1–2

We start by understanding your current state — not from a checkbox audit, but from actual artifacts. We look at your manifests, CI/CD assumptions, access patterns, existing policy posture, and the places where security and engineering are in tension.

What we review

Existing Kubernetes manifests and configurations
Current admission control setup (or absence of one)
CI/CD pipeline security assumptions
Access patterns and RBAC posture
Known friction points between platform and developers
2

Design

Days 2–4

We define a clear baseline — what should be enforced now, what should wait, and why. We make opinionated recommendations. You are not hiring us to give you a list of considerations and leave the hard call to you.

What we define

A clear baseline with rationale for each decision
Admission control direction — PSA, Kyverno, built-in, or hybrid
Implementation boundaries per environment and namespace
Exception model and annotation conventions
Ownership model — who is responsible for what
3

Deliver

Days 4–7

We produce a structured package your team can work from immediately. The exact set of documents depends on the engagement — but every deliverable is written for a specific audience and a specific purpose.

What you receive

Executive risk summary for leadership
Technical findings and baseline decisions for platform teams
Policy direction notes with reasoning
Rollout runbook with phase-by-phase sequencing
Developer impact notes written for the people doing the work
4

Optional follow-on

By arrangement

For teams that want limited advisory support during rollout — we offer a structured follow-on option. Not a retainer. Not open-ended consulting. A defined number of async review cycles for rollout questions and iteration.

What this includes

Written async Q&A on rollout questions
Policy review batch — review of updated artifacts
No ongoing Slack support or incident response

We work async by default

We do not run the engagement through meetings. Most of the work — intake, review, delivery, questions — happens through written documents. Calls happen twice: a short scoping conversation and a final walkthrough. Everything else is async.

Intake

You fill out a short structured questionnaire. We use your answers — and the artifacts you share — to drive the review. No discovery calls, no kickoff decks.

Review

We work through your materials and send written clarifying questions where needed. You respond in writing at a time that works for you.

Delivery

You receive the full document package. We schedule one walkthrough call to go through findings and answer questions. Then the engagement is complete.

This model exists because your time has value. You should not need to block a week of calendar to get a useful security baseline.

What falls outside our scope

Being clear about this protects your time and ours. These are not the right engagements for us.

Running your infrastructure

We design the operating model. We do not operate the cluster.

Incident response

We are not a 24/7 vendor. We do not provide on-call security support.

Open-ended retainers

Every engagement has a defined scope and a defined end. We do not offer monthly advisory retainers.

Generic DevOps work

We are not a generalist shop. Kubernetes security policy and rollout is what we do.

Start with the smallest engagement

A Baseline Review is a fixed-scope, async engagement that gives you a clear picture of your current posture, priority gaps, and a 30-day recommended path forward. Most teams find it clarifies more than a month of internal discussion.