Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →What to do in what order when you have just been told you need SOC 2 or ISO 27001, who to put on it, what to buy now and what to defer, and the four decisions that are expensive to reverse.
The first 90 days are not about controls. They are about four decisions that are expensive to reverse, made early and deliberately: which framework, where the audit boundary sits, which report type and observation window, and who owns the program. Get those right in the first fortnight and the remaining work is a sequence: request list, walkthrough, gap report, a remediation plan ordered by what blocks evidence rather than by severity, policies fitted to the systems you actually run, then controls producing dated artefacts with named owners. Ninety days of disciplined work reliably produces a Type I position and a running evidence pipeline. It does not produce a Type II report, because that requires a period of operation that has to be lived through. Budget $10,000 to $60,000 all-in for the first year.
The instruction almost never arrives as a considered strategic decision. It arrives as a deal blocker, and the exact wording of the blocker determines what you should do. Before anything else, find the source and read the actual sentence.
If a prospect security review asked for a SOC 2 report by a date, you have a commercial deadline and the question is what can be produced by then. If a procurement team asked whether you are SOC 2 compliant, the underlying requirement may be satisfiable with a completed questionnaire, a penetration test summary and a credible readiness position, and the report may be a year-two problem. If an investor raised it in diligence, the requirement is usually a plan and an owner rather than a report. If a customer contract already commits you to obtaining a report by a stated date, you have a legal obligation with a date on it, and that date drives everything.
The distinction matters because the wrong reading costs months. Teams routinely start a full Type II program to unblock a deal that would have closed on a Type I, and teams equally routinely promise a Type II inside a timeframe that the observation window makes arithmetically impossible. Spend two days finding out what is actually required, in writing, from the person who asked. That is the highest-return activity of the entire ninety days.
Two things are also worth checking immediately. Whether any existing customer contract already contains a security commitment with a date, since that will be discovered eventually and is better discovered now. And whether the buyer will accept a Type I as an interim step with a Type II to follow, because most will, and that answer changes the whole plan.
Make this decision in week one and then stop revisiting it. The re-litigation of framework choice in month three is one of the more expensive habits a program can develop, because it stalls remediation while people argue.
The decision is driven by buyers, not by the merits. If your customers are North American technology companies, they will ask for SOC 2, and most will not know what to do with an ISO 27001 certificate. If your customers are European, or if you sell into regulated industries outside North America, they will ask for ISO 27001, and a SOC 2 report will be read as unfamiliar. If both, start with the one your nearest revenue asks for and plan the second afterwards, because the control work overlaps heavily and the second framework is a fraction of the work of the first. Our comparison of the two sets out the practical differences, and the framework finder works through it in a few minutes.
There is a real structural difference worth knowing before you choose. SOC 2 is an attestation over a system you describe, with a boundary you define, produced by a CPA firm. ISO 27001 is a certification of a management system against a standard, with a defined scope statement, mandatory clauses covering things like management review, internal audit and risk treatment, and a three-year certification cycle with surveillance audits in between. ISO front-loads more governance documentation. SOC 2 front-loads more evidence of controls actually operating.
If a sector framework is also in play, such as a healthcare or payments requirement, decide now whether it is in scope for this cycle or explicitly deferred. Adding it in month four means re-scoping the boundary and re-running the gap, which is the expensive kind of change.
This is the decision most often made carelessly and most expensive to undo. The boundary defines which systems, which environments, which people and which locations are inside the assessment. Everything downstream is derived from it: the population an auditor samples, the controls that apply, the policies that have to be true, the evidence you have to produce.
Narrow is better, as long as the narrow version is the thing your customer cares about. If you have a SaaS platform and an unrelated services business, scope the platform. If you have production, staging and a laptop fleet, decide whether the corporate environment is in scope or only the production environment, and be aware that most buyers expect corporate identity and endpoints to be included because that is where the credentials live. If you have three products on two infrastructures, scoping one product is legitimate and common, but the report will say so and a reader will notice.
Widening the boundary later is not a paperwork change. It changes the population, which means new evidence, and for a Type II it means evidence covering the period, which you may not have for the newly included systems. Narrowing later is worse in a different way, because it looks like scope management and invites the question of what was removed.
Two practical rules. The boundary should be stated as a written system description covering the services provided, the infrastructure, the software, the people, the data and the subservice organizations you rely on. Write it in week two, even in draft, because writing it forces the boundary decision to be explicit rather than assumed. And the boundary should match what your sales team is telling customers, because the mismatch between the two is discovered by a buyer reading the report, not by you.
On a real engagement the boundary is confirmed on the kickoff call, in the first two days, before anything else happens. That is deliberate. Nothing that follows is stable until it is fixed.
A Type I assesses whether controls were designed appropriately at a point in time. A Type II assesses whether they operated effectively across a period, typically three to twelve months. The equivalent ISO decision is when the certification audit is booked, since a certification body will want to see the management system operating rather than freshly written.
The rule that governs the timeline is simple and unforgiving: a record that only exists if it was made at the time cannot be created afterwards. A quarterly access review dated last quarter cannot be run today. A visitor log for a month nobody kept one cannot be produced. A monthly security memo series assembled the week before fieldwork reads exactly like what it is, and an experienced auditor will say so. Miss those before the window opens and that period is permanently unevidenced. The only remedies are a shorter window or an opinion with exceptions in it.
This is why the window start date is a decision rather than an administrative detail. The window should begin on the date the controls genuinely start operating and producing dated artefacts with named owners, not on the date you would like the report to cover. Choosing an earlier start to make the report look better is the single most reliable way to end up with exceptions, because the evidence for the early months will not exist.
For most teams the sensible shape is a Type I as soon as the design is right, which is achievable inside ninety days, then a Type II covering a window that starts around the Type I date. That gets a report into a sales conversation quickly and produces the stronger report on a realistic schedule. The observation window planner works the arithmetic backwards from a target report date.
If a customer has demanded a Type II inside ninety days, the honest answer is that it is not available, and saying so early is better than discovering it in month three. A three-month window that starts today ends in three months, and fieldwork and report issuance follow that.
A compliance program needs three roles, and conflating them is the most common structural failure.
The owner runs it day to day: chases evidence, keeps the register, schedules the recurring records, deals with the auditor. This person needs about half their time for the first quarter and needs enough standing to ask an engineer to stop what they are doing. In a company under fifty people this is usually a technical founder, an engineering manager, or the head of operations. It is rarely a good fit for the most senior engineer, whose time is the most expensive thing being spent, and it is a poor fit for anyone whose calendar is controlled by customers.
The sponsor is an executive who can make trade-off decisions and unblock things. Their real function is to be the person who decides that a control gets fixed this sprint rather than next quarter. Without a sponsor, remediation items lose every priority argument they enter, because a compliance task always looks less urgent than a customer commitment.
The operators are the named individuals who run each control: whoever approves access, whoever reviews the logs, whoever runs the restore test. Every control needs a name against it, not a team. A control owned by engineering is owned by nobody, and an auditor asking who performed a review does not accept a department as an answer.
The question of external help is really a question about which of these you are short of. Buying a consultant does not remove the need for an owner, and a program run entirely by an external party with no internal owner collapses when the engagement ends, which is a well-documented pattern. What external help genuinely buys is the sequencing knowledge, the auditor relationship, and the judgment about what evidence will be accepted, which is the part that costs teams months when they learn it themselves. Our note on who owns compliance after readiness covers the handover problem, and the fractional CISO guide covers what leadership-level help costs.
Buy the penetration test early if you need one, because it has the longest lead time. Reputable firms book four to eight weeks out, findings need remediation, and remediation needs a retest. The typical range is $4K to $15K depending on scope. Starting this in month one and finishing in month three is comfortable. Starting it in month three is not. Our guidance on whether SOC 2 requires a penetration test covers when it is genuinely needed.
Engage the auditor during evidence collection, not after it. On a real engagement the audit firm is brought in around day thirty, in parallel with remediation, and there are two reasons. Their availability is the constraint on your report date, and firms book out. And their view on your boundary, your window and your evidence approach is much cheaper to obtain before you have produced six weeks of evidence in a form they will not accept. Auditor fees run $10K to $40K, with Type II and broader scope at the higher end.
Compliance tooling is the purchase people make first and should often make second. It runs $7K to $25K a year, and it automates evidence collection and continuous monitoring for the controls it can see through an integration, which is a genuine saving. What it does not do is decide your boundary, write a system description that matches your architecture, judge whether an artefact will be accepted, or perform a control. Buying the tool in week one and expecting it to produce a program is the most common way to spend real money and still be at the starting line in month three. Buy it once you know your control set and your boundary, which is around the end of the gap.
Defer almost everything else. Security awareness training platforms, additional monitoring tooling, a governance risk and compliance suite beyond the basic platform, and headcount can all wait until you know what the gap says. The one exception is anything that closes a gap you already know exists and that has a lead time, such as an endpoint management agent for a fleet you cannot currently enumerate.
The internal time cost is the line nobody budgets. Expect the owner at roughly half time for the first quarter, and expect several hundred hours of collective engineering and operations time across the program if you are starting from nothing. That cost is real whether or not it appears on an invoice.
The first two days are a kickoff that confirms the audit boundary and answers the scoping questions. Everything after this depends on it being settled.
By day three the document request list goes out. This is the single most useful artefact of the early program, because it converts a vague sense of unpreparedness into an enumerated list with owners. A good request list separates items into three tiers, and the tiers matter more than they look. Tier one is point in time: you either have it or you do not, and it can be sent today. Tier two needs assembling but does not depend on a period of operation. Tier three is period evidence, which only exists if the control has been running for a while, which is exactly what the assessment is trying to establish.
The tier three count on day three is the honest measure of where you actually are. A team with forty tier three items and none of them producible is a team at the beginning, regardless of how good the policies look.
By day ten the core populations should be in: the employee and contractor roster, the org chart, the joiners and leavers list for the period, and the draft system description. These are called core because everything else samples from them. An access review samples the roster. An onboarding test samples joiners. A termination test samples leavers. Without them nothing can be tested, and getting them late is the most common cause of a slipped assessment.
The most useful thing an owner can do in week two is chase those four lists rather than reading the control catalogue.
By around day eighteen the control-by-control walkthrough should be complete. This is a working session, not an interview: for each control, who performs it, how often, what it produces, and where that artefact lives. The output is a per-control record of what is actually happening, as distinct from what the policy says.
By day twenty-four the tier one and tier two evidence should be triaged, with bounced items noted. Bounced means submitted and rejected, and the reason is worth understanding early because it repeats: an undated screenshot, an export that does not show its scope, a report covering a different period, a list with no total so completeness cannot be judged. Learning the rejection reasons in week four saves weeks in month three.
By day twenty-eight the findings are written and, importantly, ranked by what each one blocks rather than by severity alone. This is the ordering principle that most distinguishes a program that finishes from one that does not, and it is counterintuitive. A medium-severity gap that prevents you from collecting evidence for six other controls outranks a high-severity gap that blocks nothing. Fixing the logging pipeline that four controls depend on comes before fixing a stronger password policy, because the first one is on the critical path of the evidence pipeline and the second is not.
By day thirty the gap report is delivered and walked through on a call, and by day thirty-two the remaining work is scoped and quoted from the gap list. That is the end of the assessment phase. A team that reaches day thirty with a written, ranked gap list and known populations is on schedule, even if the gap list is long.
The remediation plan is produced within about a week of the gap report, ordered by what blocks evidence collection. Every item on it needs a named owner within another two days. Not a team, a person, with a date.
The reason to move this fast is that remediation items decay. A gap list without owners is a document. A gap list with owners and dates is a work queue, and the difference in completion rate is dramatic. The failure pattern is a thorough gap report circulated to a group, discussed once, and then not looked at until someone asks about the audit in month three.
Two categories deserve special handling. Items that unblock evidence collection go first regardless of severity, as above. And items with an external dependency go early even if they are small: anything requiring a vendor to sign something, a contract to be amended, a subprocessor to respond, or a tool to be procured. External dependencies are the ones that turn a two-week task into a six-week task, and they do not compress under pressure.
It is also worth accepting explicitly, in writing, which gaps will not be closed this cycle. A program that pretends it will close forty items in six weeks closes twenty and discovers the other twenty during fieldwork. A program that decides to close twenty-eight and formally accept twelve, with the acceptance recorded and owned, is in a much stronger position, because a known accepted risk is a governance record and an unclosed unacknowledged gap is a finding.
By around day twenty-one of the remediation phase the policies should be drafted and, more importantly, fitted to the systems you actually run. This is where template policy sets go wrong. A downloaded information security policy that references a security operations centre you do not have, a change advisory board that does not meet, and a data classification scheme nobody uses is worse than no policy, because it creates a documented commitment you are visibly failing. An auditor tests against your own policy, so every sentence in it is a control assertion you have made about yourself.
The practical rule is that a policy should describe what will actually happen next Tuesday. If the policy says access reviews are quarterly, someone has to run one every quarter and produce a record. If it says critical patches are applied within seven days, the data has to show seven days. Where the current practice is weaker than the template, either change the practice or change the policy, and make that a deliberate choice rather than an oversight.
By around day forty-five of the remediation phase the controls should be implemented and producing dated artefacts with named owners. That phrase is the actual target, and each part of it matters. Implemented means it runs. Dated means the artefact carries the date it was produced. Named owner means a person is attached. An artefact with none of those properties is not evidence, it is a file.
This is the point at which the observation window can credibly start, and it is worth being honest about the date rather than optimistic. The window starts when the controls are actually producing records, not when the remediation plan says they will.
By day sixty of the remediation phase the evidence register should be visibly worked down, with the period evidence accumulating rather than sitting at zero. The register is the operating instrument of the whole program: one row per artefact, with an owner, a date, the control it supports and a state. Programs run out of a folder structure fail at the same point every time, which is when somebody has to answer whether the evidence set is complete.
Around day sixty-six every artefact should be reviewed against what the audit firm will actually accept, before it goes to them. This step is skipped constantly and it is the one with the highest return. An artefact bounced by the auditor during fieldwork costs a round trip of several days and consumes goodwill. The same artefact caught internally costs ten minutes. Our guide on evidence that auditors accept sets out the traits that get evidence rejected, and the evidence simulator runs an artefact through the same checks.
By day seventy-five the registers should be groomed to auditor-ready: duplicates merged, items named consistently, review states set. By day seventy-eight the evidence package is exported and handed over. Then fieldwork begins, and the discipline that matters is turnaround: a weekly cadence with the auditor and requests answered inside forty-eight hours. Fieldwork stretches almost entirely because of response latency on the client side, not because of auditor speed.
Ninety days therefore lands you at a defensible Type I position with a running evidence pipeline, or at an ISO management system that has begun to operate and has records to show for it. That is the realistic outcome of a well-run first quarter, and it is a good one.
Four decisions cost weeks or months if changed later. Everything else is comparatively cheap to revise, which is worth knowing because it tells you where to spend deliberation.
The audit boundary. Widening it means new populations, new controls, and for a period report, evidence covering a period you did not collect for the newly included systems. This can force a shorter window or a delayed report.
The observation window start date. Contemporaneous records cannot be back-filled. Choosing a start date earlier than the date your controls actually began operating guarantees exceptions for the early months, and there is no way to repair it afterwards.
The scope of criteria or controls you commit to. Adding an additional trust services category later, or extending an ISO scope statement, brings a set of controls that then need their own evidence across the window. Include only what customers require, and add later categories as a deliberate second cycle.
The ownership structure. Appointing an owner without the standing to interrupt an engineer produces a program that is always waiting on someone. Replacing that person in month three costs the context they accumulated and restarts the relationships.
Two decisions are less permanent than people fear. The tooling choice is reversible at the cost of reconnecting integrations, which is unpleasant but bounded. And the choice between doing it internally and bringing in help can be made at any point, though bringing help in during fieldwork is the most expensive moment to do it.
A Type II report. The observation window is three to twelve months and it has to be lived through, so the earliest a Type II can exist is the window length plus fieldwork and report issuance. No amount of budget compresses that. Any vendor implying otherwise is either describing a very short window or describing something other than a Type II.
An ISO 27001 certificate. Certification requires a management system with records behind it, including at minimum an internal audit and a management review that have actually happened, and a two-stage external audit. The first stage frequently identifies findings that have to be closed before the second.
A finished security program. Ninety days produces a defensible position and a working pipeline. It does not produce maturity, and the second year is where drift shows up. Controls stop operating quietly: the reviewer leaves, the scan gets muted, the policy expires without renewal.
A program that runs itself. The recurring records are the ongoing cost, and they are modest but not zero: access reviews, restore tests, a tabletop exercise, training completion, vendor reassessment, risk review, and for ISO the internal audit and management review. Put them on a calendar with owners in the first ninety days, because the failure to do so is what makes year two expensive. The compliance calendar lists what genuinely repeats.
The tool is bought first and treated as the program. Three months later the integrations are connected, the dashboard is amber, and no decision about boundary or window has been made.
Nobody owns it, or the owner has no authority. Every remediation item loses its priority argument, and the program moves at the speed of whoever happens to have a slow week.
Policies are downloaded and approved without being fitted to the systems in use, creating a documented set of commitments the company visibly fails.
Remediation is ordered by severity rather than by what blocks evidence, so the evidence pipeline stays broken while high-severity items unrelated to the critical path get fixed.
The observation window is back-dated to make the report cover a better period, and the early months turn out to have no records.
The auditor is engaged after evidence collection rather than during it, and disagrees with the boundary or the evidence approach after six weeks of work.
The core populations arrive late, so nothing can be sampled and the assessment stalls in week three with no visible cause.
Recurring records are never scheduled, so the second quarter of the window has gaps that cannot be repaired.
The penetration test is booked in month three, and the retest lands after the report date.
| Week | What happens | What exists at the end of it |
|---|---|---|
| Week 1 | Establish what was actually asked for and by when. Choose the framework. Kickoff and confirm the audit boundary. Issue the document request list. | A written requirement with a date, a framework decision, a boundary, and an enumerated request list with owners. |
| Week 2 | Name the owner, sponsor and control operators. Chase the core populations: roster, org chart, joiners and leavers, draft system description. Decide report type and window. | Named people against every role, the four core lists, and a decision on Type I or Type II with a target window. |
| Week 3 | Begin the control-by-control walkthrough. Start collecting tier one evidence, the point-in-time items that can be sent today. | Half the control set walked through, and the first tier one items submitted. |
| Week 4 | Finish the walkthrough. Triage tier one and tier two evidence and record why anything bounced. Book the penetration test. | A complete picture of what actually operates, a bounce list with reasons, and a booked test date. |
| Week 5 | Findings written and ranked by what each one blocks. Gap report delivered and walked through on a call. Remaining work scoped. | A written, ranked gap list and a scoped plan for the rest of the program. |
| Week 6 | Remediation plan ordered by what blocks evidence collection. Named owner and date on every item. External dependencies started immediately. | A work queue rather than a report, with owners, dates and the accepted-risk items recorded as accepted. |
| Week 7 | Begin remediation on the evidence-blocking items. Start auditor selection conversations. Choose compliance tooling now that the control set is known. | The critical path items in progress and a shortlist of audit firms with availability confirmed. |
| Week 8 | Draft policies from the library and fit them to the systems actually run. Engage the audit firm in parallel with remediation, not after it. | A policy set that describes real practice, and an auditor engaged with a view on the boundary and window. |
| Week 9 | Policies reviewed, approved and acknowledged. Continue remediation. Penetration test fieldwork typically lands around here. | Approved policies with dates and acknowledgement records, and a draft test report. |
| Week 10 | Controls implemented and producing dated artefacts with named owners. Schedule the recurring records: access reviews, restore test, tabletop, training. | Controls that generate evidence on their own, and a compliance calendar with owners. |
| Week 11 | Evidence register worked down. Period evidence accumulating. Remediate penetration test findings and book the retest. | A register with a visible completion state rather than a folder of files. |
| Week 12 | Every artefact reviewed against what the audit firm will accept, before it goes to them. Registers groomed: duplicates merged, naming consistent, states set. | An evidence set that has already survived an internal quality review. |
| Week 13 | Evidence package exported and handed to the auditor. Weekly cadence through fieldwork with requests answered inside 48 hours. | A Type I position or a management system operating with records, and a pipeline running into the observation window. |
A Type I, realistically yes, if the boundary is narrow and the team moves. A Type II, no. A Type II attests that controls operated across a period of three to twelve months, and that period has to actually elapse, with contemporaneous records produced throughout it. Fieldwork and report issuance follow the end of the window. The usual approach when a deal is waiting is to produce a Type I quickly to unblock the conversation, then run a Type II window starting around the same date.
Find out in writing what was actually asked for and by when. The instruction usually arrives second hand as a deal blocker, and the specific wording changes the whole plan. A prospect asking whether you are working towards SOC 2 is a different requirement from a signed contract committing you to a Type II report by a date. Teams routinely run a full Type II program for a deal that would have closed on a Type I, and equally routinely promise a Type II in a timeframe the observation window makes impossible.
Usually second rather than first. Tooling runs roughly $7,000 to $25,000 a year and genuinely automates evidence collection and monitoring for controls it can see through an integration. What it cannot do is set your boundary, write a system description matching your architecture, judge whether an artefact will be accepted, or perform a control. Buying it before you know your control set means configuring it twice. The natural moment is after the gap report, when the boundary and the control set are settled.
Because the constraint in the first quarter is the evidence pipeline, not the risk register. A medium-severity gap that prevents six controls from producing evidence sits on the critical path, while a high-severity gap that blocks nothing does not. Fixing the logging pipeline that several controls depend on before tightening a password policy is not a statement that logging is riskier. It is a statement that the program cannot produce evidence until the pipeline works, and evidence is what the deadline depends on.
Expect the program owner at roughly half time for the first quarter, plus several hundred hours of collective engineering and operations time if you are starting from nothing. That cost is real whether or not it appears on an invoice, and it is the line most often left out of a build-versus-buy comparison. It also falls disproportionately on senior engineers, because they are the people who can answer how a control actually works and who hold the access needed to produce the evidence.
Decide explicitly which gaps you will accept, record the acceptance with an owner and a rationale, and close the rest. A formally accepted risk is a governance record and reads as a functioning program. An unclosed gap that nobody acknowledged is a finding and reads as a program that lost track. The version to avoid is committing to close everything, closing most of it, and discovering the remainder during fieldwork, when there is no time and no negotiating room.
During evidence collection, roughly a month into the remediation work, rather than once the evidence is assembled. Two reasons. Their availability constrains your report date and good firms book out well in advance. And their view on your boundary, your window and your evidence approach costs almost nothing to obtain early and costs weeks of rework to obtain late. Engaging an auditor early does not compromise independence; they are not permitted to build your controls, but they can tell you what they will expect to see.
It has to start when the controls genuinely begin operating and producing dated records, and an auditor will test the early months of the period as carefully as the late ones. Choosing an earlier start date to make the report cover a more attractive period reliably produces exceptions, because the evidence for those months will not exist and cannot be created later. Contemporaneous records such as access reviews, restore tests and exercise records only exist if they were made at the time.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We scope the boundary, run the gap, and sequence the remediation by what blocks evidence, so the first quarter produces a position instead of a backlog.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.