Skip to main content
ProtoComet
ProtoComet

  • Build Trust Through Security, Governance & Control.

    Strengthen your technology foundations with a clear, practical approach to security, governance, and compliance. Identify risks, establish the right controls, and align your technology landscape with business priorities and regulatory requirements

Where this actually breaks

Security gaps rarely announce themselves. They surface when a customer asks for proof, an auditor asks for evidence, or someone leaves and their access doesn’t.

The questionnaire arrived and nobody can answer it

A prospective customer sends 200 questions about access control, encryption, logging and incident response. Your answers are probably fine. Nobody can say so with evidence, and the deal waits while engineers piece together how their own estate works.

Everyone who ever needed access still has it

Owner rights granted to unblock a release and never revoked. A contractor who left last year still in the tenant. Service principals with rights across the whole estate. Access is whatever piled up, and nobody can produce the list of who can do what.

Policies report, but nothing enforces

Azure Policy set to audit, because enforcing might have broken something on the day it was switched on. The dashboards have been red so long they’ve stopped meaning anything.

Nobody could tell you whether you’d been breached

Sign-in and activity logs kept for days or weeks by default, spread across subscriptions, and never reviewed. If a customer asked what happened last quarter, the honest answer would be that nobody knows.

Govern by decision, not by dashboard: the sequence

Two checkpoints happen before anything moves. Three repeat with every wave. One closes the programme. Each ends in a short written decision that everyone works from, so the plan, the build and the sign-off are all checked against the same record.

1. Control baseline

Your contracts, customer questionnaires, target framework and any regulation that applies, turned into one list of controls, each with an owner. Not a framework’s full catalogue: only the controls that apply to you, with the reason for each exclusion written down.

Output: Control register

2. Identity and access

Who and what can do what, and where. MFA and conditional access for every person, groups instead of individual grants, managed identities instead of stored secrets, admin rights that expire, and a joiner-leaver process that actually removes access.

Output: Access model and clean-up plan

3. Boundaries

Which networks can talk to which, what is reachable from the internet, where each class of data may live, and how it’s encrypted. These are the lines the next step enforces.

Output: Network and data boundary design

4. Policy as code

Azure Policy rules mapped to the control list, kept in version control and reviewed like any other change. They start in report-only mode and move to blocking in stages, with a process for exceptions.
Output: Policy set in a repository; exception register

5.Logging and evidence

Logs centralized and kept for as long as your obligations require. Each control mapped to the query, policy state or log that proves it, so the evidence pack is generated, not assembled. Includes a short incident runbook, so “what would we do” has an answer.

Output: Evidence map

3. Cadence

Monthly: expiring exceptions, policy drift, access changes and new findings. Quarterly: the control list checked against what changed in your obligations and your estate. Each review has a named owner on your side, with ProtoComet alongside until it runs without us.

Output: Governance calendar

How the work actually runs

A fixed-price baseline, then either a defined move to the next level or a monthly cadence. This is advisory and design. It isn’t a penetration test, a managed security service or a certification audit, and it gets you ready for all three. No tool resale and no reseller margin: if a product is recommended, it’s because the control needs it.

Baseline, fixed price


Typically two to five weeks engagement. You get the list of controls you actually have to meet, your estate checked against it, and a prioritized plan to close the gaps. If a questionnaire, customer deadline or audit date is driving this, the plan is ordered around that date. Access required is read-only, with no write rights. From you: one engineer for a few hours a week, plus whatever already exist.

Move or maintain


Moving a level is a fixed-scope engagement with your platform team making the changes and ProtoComet designing, staging and reviewing them. If you have no one to make them, ProtoComet can, within the same scope. Maintaining the level is a monthly retainer: the cadence, the exception register, and a standing line for the "can we just" questions that erode governance one at a time.

What senior-only means here


The person on your first call does the work. They don’t hand it to a junior team after the contract is signed. The same person decides which controls apply, checks each policy change , approves or rejects exceptions, and joins the call when a auditor asks how something works. You never re-explain your estate to someone new, and you never pay for anyone to learn on your engagement.


What you walk away with

Everything a customer, an auditor or a new engineer needs to understand how your estate is secured, plus controls the platform enforces without anyone having to remember. All of it is yours: documents in your format, policy code in your own repository.

➖ Control register. The controls that apply to you, each traced to its source (a contract, a framework or a regulation) and given an owner.


➖ Gap assessment and plan. Where your estate stands today, in plain terms, and the prioritized route to close the gaps, ordered around your deadline if you have one.


➖ Access model and clean-up plan. Who should be able to do what, and the order for removing leftover admin rights, old accounts and stored secrets without breaking anything.

➖ Boundary and policy design.Segmentation, private connectivity and data classification, with where each class may live.


➖ Evidence and logging. Each control linked to the log, query or policy state that proves it, plus log retention and a short incident runbook. Evidence is generated, not assembled.


➖ Security answer pack. Standard answers to the questions customers ask most often, each linked to its evidence, so the next questionnaire starts from a finished draft.

Our Way

I have been the engineer who asked for Owner on a subscription to get a deployment unblocked on a Friday, and got it, and never gave it back. I have set a policy to audit mode because deny would have broken the release. Every accumulated estate is made of decisions like those, taken by reasonable people under deadlines, and a governance model that does not understand that will be worked around within a month.

So this practice starts from the regulation, not the tooling, and it designs the exception process before it turns on the first deny. Engineers will comply with a governance model that has a fast, written way to say "not this time, and here is until when". They will route around one that does not.

The other principle is that evidence should be a by-product. If proving a control requires a person to take a screenshot, the control is not really in place. It is being performed.

A red compliance dashboard that everyone has stopped looking at is not a governance problem. It is the absence of a decision about what the dashboard is for.


Yogesh, founder and principal consultant

Questions clients typically ask

Answered directly. If the honest answer is "it depends", the dependency is named.
No, but only because it’s sized to you. A startup with one subscription and a SOC 2 deadline needs a short control list, a clean access model and evidence that holds up. It doesn’t need an enterprise programme. If you’re genuinely too early, for example with no customer asking and nothing in production, we’ll say so on the first call and tell you the three things worth doing now.
Neither. A penetration test finds ways in; this designs the model that decides what should be possible in the first place, and it will recommend a test once the model is in place so the test measures something stable. If what you need is a test, you will be told so in the first conversation and pointed to firms that do it well.
Yes, if it is done all at once, which is why it never is. Each initiative moves to deny at one scope at a time, after the audit results at that scope have been reviewed and the exceptions written. The engineers are usually right about which deployments would break. They are usually wrong about how many, because most of the red on the dashboard is resources nobody uses.
It gets your Azure estate ready and gives it evidence that holds up, which is usually the hardest part. Certification itself needs an accredited auditor, and the scope covers more than Azure: written policies, HR processes, laptops. We cover the Azure side, flag the gaps elsewhere, and work alongside your auditor or compliance platform. We don’t certify, and we won’t pretend to.

Ready to move?

Let's talk about where you are and where you want to go.  and whether modernization is even the right answer this year. If it is not, you will hear that.

Let’s Talk