The product, end to end.
SAGEN Cyber Readiness is our product. It connects verified security evidence to the business systems that depend on it, prioritizes what to address, supports the customer through remediation, and prepares evidence the customer controls for sharing with an insurer.
It is available to customers today.
Organizations can usually describe their security posture and rarely prove it. Evidence sits in different tools, ages quietly, and gets assembled by hand whenever a customer, an auditor, or an insurer asks. The product replaces that scramble with a continuous record.
Four ideas make it different from a security dashboard. Evidence carries its own confidence, so a figure never travels without an indication of how much it can be relied on. Technical exposure is connected to the business system it affects. Remediation is verified against new evidence rather than a completed task. And what gets shared outside the organization is approved by the customer, scoped, and frozen at a point in time.
It is not a scanner, not an antivirus product, and not something that changes anything in the customer's environment. It observes, organizes, explains, and verifies.
When you introduce it, lead with proof rather than detection. Most buyers already own tools that find problems. Very few can demonstrate the current state of their estate to someone who is entitled to ask.
Cyber Readiness turns scattered security data into evidence a customer can stand behind.
The product exists because organizations cannot answer a simple question on demand: what is our current security state, and how confident are we in that answer.
Most have tools that find problems. Very few can show a coherent picture at a given moment, backed by evidence, to someone entitled to ask. That gap costs them in four ways.
The annual scramble. A questionnaire, an audit, or a renewal arrives and someone spends weeks collecting screenshots. The result is a point-in-time picture that was already stale when it was assembled.
Severity without context. A vulnerability list ranks by technical severity, which says nothing about whether the affected machine matters. Teams work the list from the top and still leave the important thing exposed.
Closure without proof. A ticket is marked done. Nobody checks whether the exposure actually went away, and the organization believes a risk was resolved because someone reported it was.
Sharing without control. Providing evidence to a broker or an insurer means sending documents nobody can retract, or granting access nobody wanted to grant.
Underneath all four is the same thing. The organization has security data and does not have security evidence. Data is what a tool produces. Evidence is attributable, current, and defensible when questioned. Where it is absent, that absence is reported honestly, because missing evidence is not proof of safety.
The product does not solve every security problem. It does not detect an attack in progress, replace a security team, or make an organization secure on its own.
In a conversation, find which of the four is hurting. A prospect deep in a renewal cares about the scramble. One who just failed an audit cares about proof.
They have security data. What they need is security evidence.
Two kinds of organization use the product, and they open the same workspace.
A direct customer sees the workspaces they are authorized for. A service provider, such as a managed security provider or an advisor, sees a portfolio of the customers who granted them access.
The URL and the workspace are identical in both cases. What differs is what the person is authorized to see and do.
Access is decided by the platform on every request, never by the browser. A person's role and grants determine what appears. Roles cover client administrators and viewers on the customer side, and provider administrators, security operators, and viewers on the provider side.
A business relationship grants nothing by itself. A provider working with a customer sees that customer's data only when an active, explicit grant exists. It can be revoked, and removing someone's membership blocks their very next request rather than waiting for a session to expire.
This matters commercially. The product is sellable through service providers as well as directly, which is a second route to market and a different economic shape. It also answers the question a cautious customer asks about whether their advisor could see more than intended.
The customer's own users do not see other customers. Isolation is enforced by the platform, and an unauthorized identifier returns the same not-found response whether or not that customer exists.
One workspace, and authorization decides what each person sees.
Onboarding follows one path. The customer is set up, their people are invited, and devices are enrolled. Evidence begins arriving as soon as the first device reports.
The step customers care about is device enrollment, because it is the one that touches their machines. Each installation uses a short-lived, single-use activation code issued for that campaign. There is no shared password to circulate, and a leaked code does not grant access to the platform or to anyone else's data.
Enrollment is bounded by what the customer is entitled to. A customer entitled to fifty devices cannot be sent invitations for sixty.
A device moves through registered, provisioning, and active as setup completes. Separately it reports connectivity as online, offline, or unknown. Those are two different things. A device can be fully set up and currently offline, and reading one as the other is the most common early mistake.
Windows, macOS, and Linux are supported.
Onboarding is not instant and should not be described as such. Evidence accumulates as devices report, and the first useful picture arrives once enough of the estate is enrolled rather than after the first machine.
Say the product is available and that onboarding is straightforward. Do not commit to a deployment date in the room. Confirm the schedule with delivery, the way any technology company does. A date promised in a meeting and missed costs more than the meeting gained.
Available today. Agree the schedule with delivery, not across the table.
Evidence is the central idea of the product. An observation from a device, a document, or a declared fact becomes an attributable record: what was seen, when, from where, and how much it can be relied on.
Evidence is normalized once and reused everywhere. The readiness picture, the system exposure view, the remediation workflow, and anything shared externally are all derived from the same records rather than assembled separately.
That single detail is why the product holds together. When each view has its own source, the organization ends up with competing versions of the same fact, and the version someone quotes depends on which screen they opened. Here the customer, their advisor, and a recipient outside the organization are looking at derivations of one record.
Three kinds of input become evidence. A technical observation from a device carries the most weight. A document supports a claim. A declaration is something the organization states about itself, such as which business service a machine supports.
They are not equal, and the product never treats them as equal. A self-reported answer and a validated technical observation both belong in the record, and each carries what it is.
Evidence is not raw log data and the product does not present it as such. Raw collection stays where it was produced. What enters the record is a normalized, bounded summary.
Evidence is normalized once, and every view is derived from the same record.
Confidence answers a question most security tools never ask: how much can this figure be relied on. Every score in the product travels with a confidence alongside it, and the two are never merged.
A number without confidence is an assertion. A number with confidence is a finding. An organization presenting its security state to an auditor, a board, or an insurer needs to say not only what it found but how firmly it knows it.
Confidence is not one property. It is composed of several dimensions.
| Dimension | The question it answers |
|---|---|
| Source reliability | Was this a technical observation, a document, or a declaration |
| Freshness | How recently was it captured or confirmed |
| Coverage | How much of the relevant environment does it actually speak to |
| Consistency | Does it agree with related findings and records |
| Integrity | Does provenance support the record |
What the customer sees today is a single confidence value with a band of high, medium, or low, and freshness reported alongside it. The dimensions above are the model the confidence expresses, not five separate figures on screen.
That distinction matters in a demonstration. Describe the model, then show what appears. Promising five visible sub-scores creates a gap between the pitch and the product.
When confidence is too low, the product withholds the score rather than showing a reassuring one. That is deliberate restraint and the strongest thing to say about it.
Confidence is not a measure of how secure an organization is. A high-confidence bad result is still bad.
Missing evidence is not proof of safety.
The product summarizes a customer's endpoint security state as a score, with its evidence confidence reported separately. The score says how things stand. The confidence says how much that reading can be relied on.
A single blended number would be worse than useless. An organization with thin evidence and a flattering score would believe something the data does not support, which is exactly the failure the product exists to prevent.
The score is expressed as a value with a band, running from strong through managed, at risk, and critical. Its inputs include exposure, policy state, and remediation history, together with the underlying device and finding counts. When there is not enough to work with, the state is reported as insufficient data and any earlier value is labeled as last known rather than current.
A withheld score is not a bad score. It means the product declined to grade on evidence it does not have. Present that as restraint, because it is the single most misexplained part of the product and the easiest thing to get backwards in a meeting.
A richer grading model with weighted domains exists in the product and is currently in calibration rather than customer-authoritative. Do not present it as something a customer will see today.
The score is not a compliance rating, not an ISO or SOC result, and not a measure of breach likelihood. It describes endpoint security posture.
The score says where you stand. The confidence says how much to trust it.
The product shows every enrolled device in the customer's estate, what is technically true about it, and what the business has declared about it. Those two layers are kept separate and labeled.
A machine's technical facts do not say whether it matters. A vulnerability on a test server and the same vulnerability on the system that issues invoices are the same finding and a different problem. Only the organization can supply that context, so the product asks for it and records who declared it.
| Layer | What it holds |
|---|---|
| Observed | Hostname, operating system, architecture, agent version, connectivity |
| Declared | Business owner, business service, environment, criticality, data classification, internet exposure, lifecycle, region, tags |
Criticality is judged by the business impact of losing the asset, not by the severity of anything found on it. Low means limited disruption with a workaround. Mission critical means an essential service stops.
Unknown is a valid state and stays unknown. The product does not infer a business owner, guess a criticality, or fill a blank with a default. An unclassified asset is visibly unclassified, which is information rather than an absence of it.
Devices report two independent things. Setup progresses through registered, provisioning, and active. Connectivity is separately online, offline, or unknown. A device can be fully active and currently offline, and reading one as the other produces confident, wrong statements.
Declared context does not change anyone's permissions and does not by itself make an asset important to the platform.
Technical facts come from the device. Business meaning comes from the customer.
A finding is a normalized security observation about a device. It comes from one of two sources: an alert, meaning something happened, or a vulnerability, meaning something is exposed.
Raw security tooling produces volume rather than clarity. The same issue appears many times, in different formats, without any indication of whether it is new, recurring, or already known. Normalizing turns that into a list a person can work through.
Each finding carries what it is, where it was seen, and its history.
| Field | What it tells you |
|---|---|
| Source | Alert or vulnerability |
| Severity | How serious the source rated it |
| Device | Which machine it concerns |
| Occurrences | How many times it was observed |
| First and last seen | Whether it is new, persistent, or old |
| Reopened | Whether it came back after being closed |
The reopened date deserves attention. An issue that returns is a different conversation from one that never went away, and it usually points at a change that did not hold.
The product does not decide finding state. It does not acknowledge, suppress, or resolve findings, and it does not invent a severity. What it presents reflects the underlying security record.
A finding is not proof that something was exploited. A vulnerability means an exposure exists, not that anyone used it.
Never read a short findings list as good news without checking freshness. An empty list on a customer whose collection stopped looks identical to an empty list on a customer with nothing wrong.
A finding tells you what was observed, not what happened.
A critical system is a business capability the organization depends on, such as billing or customer records. The product connects the technical findings on individual machines to the business system those machines support, and reports how exposed that system is.
A vulnerability on a server is the beginning of the story rather than the end. What a decision-maker needs to know is which business capability is affected, how much it matters, and why this exposure deserves attention ahead of the others. Severity alone cannot answer that.
Exposure is reported in bands: pending, none, low, elevated, and severe. Pending means the assessment has not produced a result yet, which is not the same as none.
Each system carries its own confidence and freshness, the same way a score does. A severe exposure on stale evidence is a different statement from a severe exposure on current evidence, and both are shown for what they are.
The count shown against a system is open evidence items. It is not a vulnerability-only count and not a recent-alerts count. Comparing it against a number from a different screen produces a discrepancy that is not real.
This depends on the customer declaring which assets support which business service. Where nothing has been declared, the product falls back to findings alone rather than inventing a business map. One service field per asset also cannot describe a shared-host dependency graph, and the product does not pretend otherwise.
Exposure explains which business capability is at risk, not just which machine is affected.
The product proposes what to address first and states the basis it used. It is a short, ordered list rather than an exhaustive one, and each entry carries the reason it ranked where it did.
Security teams do not fail for lack of a list. They fail because the list is long, unordered by anything meaningful, and worked from the top by severity until attention runs out. Ranking that accounts for business context puts the right item first.
Two ranking bases exist. When business systems have been declared, ranking is system-weighted and accounts for what the affected capability is worth. When nothing has been declared, it falls back to finding severity.
The basis is always reported, including when it fell back. A customer asking why an item is first gets an answer from the product rather than an improvisation from the person presenting.
Ranking accounts for declared criticality, exposure, and the protected systems involved. Where criticality is unknown or an asset is unassigned, that is handled explicitly rather than treated as low importance.
AI does not choose the order. The ranking is deterministic and stated. An explanation may help a person understand an item, and it never decides where the item sits.
This is not a universal severity ordering and the product does not claim one. It is a recommendation based on what the customer has declared and what the evidence currently supports.
The product says what to do first, and says why.
The product can generate an explanation of a finding: what it means, why it matters in context, and what a reasonable response would be. The explanation is advisory, grounded in that specific finding, and versioned.
Security findings arrive in the language of the tool that produced them. A person who has to decide what to do needs it in the language of consequence, and writing that by hand for every finding does not scale.
Three properties define what these explanations are.
Grounded. The explanation is generated from the finding and its evidence, not from general knowledge about the vulnerability class.
Advisory. It informs a decision. It does not make one, does not change a finding's state, and does not rank anything.
Hypothetical where it describes attack paths. A described path is a way an attacker could proceed. It is not evidence that anyone did.
That last point is where employees overreach most often, and it is where a technical evaluator will probe hardest. A described path presented as an incident is a serious misstatement.
Explanations are available where the customer's access permits, and they are not generated for every routine alert.
If explanations are unavailable, the findings and evidence underneath are unaffected. Nobody should delay acting on a critical item because no explanation was produced.
The restrained version of this story is the persuasive one. Every vendor claims AI. A vendor who says plainly that theirs explains and does not decide sounds like one that has thought about the failure modes.
Our AI explains findings. It does not rule on them.
This is the workflow the product exists to run. It takes a technical exposure and carries it through to a fix confirmed by new evidence.
Most organizations can find problems and cannot demonstrate they closed them. Work is marked complete, everyone moves on, and nobody establishes whether the exposure actually went away. This workflow closes that loop.
Identify. A finding is connected to the business system it affects, with technical exposure and declared business context labeled separately.
Explain. What could be affected, and how reliable the evidence is. Source, freshness, coverage, consistency, and integrity are considered before anyone relies on it. Missing evidence stays unknown.
Define and implement. SAGEN explains the required outcome and what evidence would prove it. The customer or their IT provider assesses the change, obtains approval, implements it, and retains rollback responsibility.
Verify. A new observation is checked against the original finding. If the exposure persists, the finding stays open. A customer who decides to accept the risk instead has that recorded as its own decision.
The product never takes autonomous action in the customer's environment.
Walk a prospect through these five steps rather than describing features. It is the clearest demonstration of what the product is for, and it lands the remediation boundary without sounding defensive.
A completed task is not a verified fix.
Cyber insurance underwriting depends on what an organization can demonstrate about its security. The product prepares that evidence continuously and lets the customer share an approved package for a submission.
Four parties appear in this story.
| Party | Their role |
|---|---|
| The insured | The customer. They own the evidence and approve what leaves |
| The broker | Places the risk and needs a credible submission |
| The carrier | Underwrites it and needs evidence they can rely on |
| SAGEN | Produces the evidence and the means to share it |
Today a submission is assembled by hand from screenshots and questionnaire answers, at a point in time chosen by the deadline rather than by the data. Both sides know the picture is thin. The insured cannot easily prove what is true and the carrier cannot easily verify what they were told.
Continuous evidence changes the conversation. What the insured shares is attributable, carries its own confidence, and reflects an actual state rather than a recollection.
The carrier never receives access to the customer's environment. They review a package the insured approved, scoped to a purpose and frozen at a point in time. Access can be revoked, and later changes require a new review.
The product does not underwrite, does not price risk, and does not guarantee any insurance outcome. It prepares evidence. What an insurer does with it is theirs.
Be careful with this story in a meeting. The valuable claim is that the insured controls a credible submission. Anything that sounds like giving an insurer a window into their systems will end the conversation.
The insured decides what is shared, with whom, and for what.
Controlled disclosure is how evidence leaves the customer's control on their terms. The customer selects the recipient, the purpose, and the scope, and approves the release. What the recipient receives is a frozen package.
Sharing security evidence is normally a bad choice between two options. Send documents, which cannot be retracted and go stale immediately. Or grant access, which gives a third party more than the situation warranted and for longer.
A frozen package is neither. It preserves exactly what was approved and when.
| Property | What it means |
|---|---|
| Approved | The customer authorizes the release before it happens |
| Scoped | Only the evidence selected for this purpose |
| Purpose-specific | Tied to a submission or request, not standing access |
| Time-bound | Not permanent |
| Frozen | A snapshot with its timestamp, including remaining uncertainties |
| Revocable | Access can be withdrawn |
The package records what was uncertain at the time as well as what was known. That sounds like a weakness and is the opposite. A recipient who can see the limits of the evidence can rely on the rest of it.
A frozen package is not continuous assurance. It describes one moment. Later changes require a new review and a new release, and a recipient should not treat last quarter's package as today's state.
The package is not live access, not a feed, and not a standing permission. A recipient reviews what was released and nothing else.
This is the answer whenever someone asks what an insurer or auditor can see. The short version is that they see what the customer approved, and only that.
The customer approves every release, and the package is a moment rather than a window.
This chapter is deliberately blunt. Every item is something a prospect might assume, and each one is easier to say now than to retract later.
It does not change anything in the customer's environment. No configuration, no patching, no isolation, no remote commands. It observes, organizes, explains, and verifies.
It does not decide finding state. It does not acknowledge, suppress, or resolve a finding, and it does not invent a severity.
It does not take autonomous action. Nothing in the product acts on the customer's systems without a person deciding.
Its AI does not rule. Explanations are advisory and grounded. A described attack path is hypothetical, never evidence that exploitation occurred.
It does not give anyone live access to the customer's environment. External recipients see a frozen package the customer approved.
It does not certify, audit, or attest. Those are performed by independent bodies. The product supports the preparation.
It does not rank one customer against another. Provider views summarize each customer separately and do not produce a league table.
It does not treat missing evidence as a pass. Absence is reported as unknown or not assessed and never quietly improves a result.
It is not a scanner, an antivirus product, or a detection service. It does not tell a customer they are under attack right now.
One more distinction, because it causes more trouble than the rest combined:
A capability existing somewhere is not a capability available to this customer. When you do not know which of the three applies, say you will confirm.
When in doubt, say what the product does not do. It is always the safer sentence.