Frequently asked questions

Maturity is scored 0 to 5 for each capability, and certain answers in your CAMP assessment act as gates. A gate question caps how high a capability can score until the underlying practice is in place. If you answered that a process exists but is undocumented or inconsistent, the capability cannot reach the higher levels that require it to be Defined, Quantitative, or Optimized.

This is intentional. A capability is only as mature as its weakest foundation. You cannot be measuring and optimizing a process you have not yet documented.

To move up, revisit the gating answers for that capability. The scoring is deterministic, so once the foundational practice is reflected in your responses, the cap lifts and your maturity reflects the higher level.

Pytheus always traces a score back to the inputs that produced it, so you can see exactly which answer set the ceiling.

Unknown means a capability has not yet been assessed. You have not answered the CAMP questions for it, so Pytheus has no maturity value to score.

This is different from a maturity of 0, which means None: you assessed the capability and confirmed the function does not exist. Unknown is the absence of an answer, not the absence of a control. Pytheus treats absence of evidence as Unknown, never as a quiet No.

Pytheus keeps Unknown capabilities visible rather than guessing, because an honest gap in your assessment is more useful than an invented score. Unknown capabilities do not contribute to your Org Score or domain scores until you complete them.

To resolve them, return to the CAMP assessment and answer the open capabilities. The more you complete, the higher your capability coverage, which is one of the inputs to your Pytheus Score.

Yes. CAMP is your baseline assessment, and you are meant to revisit it as your program changes. Security maturity moves over time, and your assessment should reflect that.

You can update individual capability answers as practices improve, or work back through the full assessment when you want a fresh baseline. Because scoring is deterministic, updated answers immediately recalculate your maturity, Org Score, domain scores, and the recommendations that flow from them.

Reassessing is the normal way to show progress. As you close gaps and lift gated capabilities past their previous caps, your scores rise to match the work you have done.

A useful rhythm is to reassess after major changes, such as a tool rollout or a process you have newly documented, so your scores stay aligned with reality rather than drifting out of date.

A board priority is a business outcome with a deadline: comply with a standard, enter a market, close a deal that depends on a security review. A roadmap goal is the security work that supports it.

The distinction matters because they are read by different people. A board recognizes the priority and does not recognize the roadmap goal. Connecting the two is the whole point of Board Alignment: leadership sees the outcome, and you can show the work underneath it.

Pytheus proposes which capabilities a priority depends on, based on the template and the shape of the outcome. Until a person confirms a mapping, it stays a suggestion and is labeled as one.

That is deliberate. A readiness number built on unreviewed guesses is worse than no number, because it looks authoritative. Confirming takes seconds and is what makes the rest of the picture trustworthy.

No. It is derived from your own assessment and your confirmed mappings, and it is a reasoned starting point for a conversation with finance rather than a commitment.

If it looks wrong, the cause is usually upstream: a capability assessed optimistically, a required level set higher than the outcome needs, or a mapping nobody reviewed. Fix the input rather than arguing with the output.

Modeled redundant spend is the money Pytheus estimates you are paying for a capability that more than one tool already covers. It is a flag to investigate, not a guaranteed saving and not advice to cancel a tool. Some redundancy is deliberate, for example double-covering a compliance-required capability. You will find it in the Cost Center, on the Spend surface.

Open the Spend surface in the Stack group. The Cost Center shows total annual spend, spend by domain and vendor, where tools overlap, upcoming renewals, and a side-by-side comparison of any two tools. See The Cost Center.

Your Annual Spend is the total recorded run-rate across all tools. The spend-by-domain breakdown only counts spend that maps through a capability to a domain. A tool with no capability mapping still sits in your total but lands in no domain, so it is unattributed.

That difference is a prompt, not a bug. The shortfall is unattributed spend waiting to be explained. Map the tool to the capabilities it delivers and that money joins the correct domain. See Annual spend and attribution.

Pytheus classifies each upcoming renewal into one of three outcomes so the urgent ones stand out:

• Actionable: a decision is needed now, because the renewal or its notice deadline is close.

• Monitor: worth watching, for example a renewal is approaching but its auto-renew terms are unknown, so confirm them.

• Insufficient data: not enough is recorded on the contract to classify it.

Crucially, unknown auto-renew terms are never silently treated as "no action needed." An unconfirmed auto-renew clause lands in Monitor with a nudge to confirm, so nothing quietly locks you into another term. See Renewal decisions.

They are two halves of the same workflow. Decisions is where you evaluate ranked recommendations and approve or reject them. Roadmap is where you execute the work you approved.

When you approve a recommendation on the Decisions surface, Pytheus records the decision and creates a corresponding action on your Roadmap in one step. The Roadmap then sequences that action by priority, breaks it into tasks, and projects how your scores improve as it lands.

Decisions was previously called Recommendations; that surface has been folded in, so there is no separate Recommendations page anymore. See What the Decisions surface is.

Every recommendation is capability-driven and generated from your CAMP assessment using deterministic rules. Pytheus calculates priority for each capability as how far a capability is from its target, weighted by how critical it is, then surfaces the capabilities where the weighted gap is largest.

A capability that is compliance-required (criticality 3) and sits well below its target will outrank a nice-to-have that is only slightly behind. That is why a recommendation can move up the list even when its raw maturity gap looks modest.

Because the rules are deterministic, you can trace any recommendation back to the inputs that produced it: the capability, its current and target maturity, and its criticality. Nothing is generated by guesswork.

If a recommendation does not match your intent, adjust the inputs behind it. Change the target or revisit the criticality, and the priority recalculates accordingly.

Evidence answers how much of your posture you can actually prove, as distinct from what you have claimed in your CAMP answers. It maps your framework controls to the capabilities behind them and classifies each control by the strongest proof it holds. It never changes your Pytheus Score; it tells you how much of that score you could defend.

Each control lands in one of six states:

• Verified: fresh, independent evidence backs it.

• Provisional: attested or partial, not independently proven.

• Needs review: contradicting evidence with no fresh support.

• Conflicting: an unresolved yes-versus-no conflict.

• Stale: the only supporting evidence is out of date.

• Missing: no evidence touches it yet.

A self-reported CAMP answer alone never earns Verified: the claim is not the proof. See The six verification states.

No. Readiness is derived from your capability assessment through a published mapping between capabilities and requirements. It is good at telling you where you are clearly short, which is the useful thing to know before an audit.

It is not an audit, it produces no attestation, and it will not tell you that you have passed. Controls whose mapping is still under review are labeled as such rather than presented as settled.

A thorough CAMP assessment usually needs input from across your security program, so Pytheus lets you bring contributors into the work rather than answering everything alone.

From the Team surface, invite teammates to join your organization and contribute to the assessment. New members default to the Contributor role. Spreading the work matters because the people closest to each function give the most accurate answers: your identity lead knows the real state of provisioning, your operations team knows how incidents are actually handled, and that accuracy is what makes your scores trustworthy.

Contributors answer the capabilities they own, and the scoring stays deterministic regardless of who entered the input. Every result still traces cleanly back to the answers behind it. The more accurate the inputs, the more your Pytheus Score, benchmarks, and recommendations reflect your real program.

Benchmarks compare your performance against a pooled, anonymized average of organizations in your sector and size cohort. Pytheus measures the same criticality-weighted maturity it applies to you against the aggregate performance of similar peers, and shows the difference as a peer delta.

No. Your assessment data, capability scores, contracts, and roadmaps belong to your organization. When Pytheus compares you to your cohort, it shows pooled aggregates, never any named organization's record. You see how you compare against the group, and no other organization sees your individual results.

A peer delta is a performance difference, not a gap. A gap is the distance between your current maturity and your own target. You can sit below the cohort on a capability you deliberately deprioritized, and that is a defensible choice, not a deficiency.

The Pytheus Score is your headline number from 0 to 100, shown on your dashboard. It combines four inputs:

• Org Score: your criticality-weighted maturity across in-scope capabilities, also scored 0 to 100.

• Goal Alignment: how well your current state tracks against the targets you have set.

• Coverage: how much of your program you have actually assessed rather than left unknown.

• Execution Discipline: how consistently you are following through on the work your assessment implies.

Each input comes from your own data: your CAMP answers, your targets, and your progress. The calculation is deterministic, so the same inputs always produce the same score, and you can trace the headline number back to the four components beneath it.

The largest lever is Org Score, since it carries half the weight.

Org Score carries the most weight, because maturity is the truest measure of how a program performs today.

Changing a target maturity changes the gap for that capability, and the effects flow through deterministically.

Priority recalculates first. Since priority is how far a capability is from its target, weighted by how critical it is, raising a target widens the gap and pushes the capability up your recommendation list. Lowering it narrows the gap and moves the capability down, or off the list once you have met the new target.

Your roadmap projections update to reflect the revised destination, and goal alignment, one of the inputs to your Pytheus Score, shifts based on how your current state tracks against your stated targets.

Your current maturity does not change. A target is where you intend to be, not where you are.

Set targets to reflect what your organization actually needs, not the maximum possible. A target of 5 on a nice-to-have capability will distort your priorities.

The Pytheus Index is anonymized, opt-in peer benchmarking. It shows how your program compares to a pooled cohort of organizations in your sector and size band, on both your score and your spend.

You see your percentile within the cohort, the cohort median and quartiles, a peer distribution, and per-domain standing, plus how your per-tool and per-domain spend compares. No single peer's data is ever shown, and no peer identity leaves the aggregation layer.

This is peer intelligence, not market data: the figures come from real, assessed programs, pooled and anonymized, not from a vendor price list. Cohorts below a minimum sample are suppressed, and the extremes are withheld, so small cohorts cannot expose their members. See What the Pytheus Index is.

This surface may not be enabled for your organization yet. Your Pytheus contact can confirm.

Requiring single sign-on turns off password sign-in and password reset together, so the platform will not let you raise the policy until three things are true: an enabled connection exists, it passes a live validation check, and somebody has actually completed a real sign-in through it recently.

Relaxing the policy is never blocked, because that is how an administrator recovers. If you are stranded anyway, your Pytheus contact can clear the policy. It needs a written reason and is recorded in your own audit trail as well as ours.

Use one of the recovery codes you were given when you enrolled. Each works once. After signing in, enroll your new device and regenerate the set.

If you have no codes and no device, an owner or admin in your organization can reset your enrollment. If you are the only owner, your Pytheus contact can help. Nobody at Pytheus can see your codes or your authenticator secret.

Contribution is a read-only recognition of the verified improvement a person helped deliver. Pytheus computes it from the maturity gains tied to outcomes that were actually verified, credited to the people who participated, and weighted by how they took part: direct ownership counts fully, shared participation counts less, and supporting participation counts least. It reflects a recent window and never falls below zero.

It is deliberately not a competitive leaderboard. The member list is ordered by name, not by score, and because only verified outcomes count, it cannot be gamed by logging activity. See Roles and contribution.

My Work is your personal command center. It brings together what is on your plate: your impact from verified outcomes, a short focus list of the highest-value work in the domains you own, your open task queue, upcoming contract renewals in your remit, and any cross-team dependencies waiting on you.

It respects your permissions, so feeds your role cannot see simply do not appear. Everything on it links back to the roadmap action, contract, or outcome behind it, so it is a lens on real data rather than a separate to-do app. See My Work.

This surface may not be enabled for your organization yet. Your Pytheus contact can confirm.