Language, claims, and the hard questions.
Section 3.16 covered what the product does not do. This chapter is company-wide, and it is deliberately blunt. Each item is something someone might assume, and each is easier to say now than to retract later.
We do not implement changes in a customer's environment. Not in services, not through the product. We identify, explain, prioritize, and verify.
We do not certify, audit, or attest. An independent licensed firm performs a service organization examination. An accredited body issues a certification. We prepare organizations and support them through the process.
We do not rule on what regulations apply to a customer. Applicability is a legal question. Where it is uncertain, it goes to qualified review.
We do not guarantee a security outcome. No engagement and no product makes an organization secure, and no honest firm claims otherwise.
We do not guarantee an insurance outcome. We prepare evidence. Underwriting belongs to the carrier.
We do not treat missing evidence as a pass. Absence is reported as unknown. Missing evidence is not proof of safety.
We do not present illustrative material as real. The sample dashboard and sample report published on our website use fictional data and say so. Never describe them as a customer result, in a meeting or in a deck.
One distinction causes more trouble than the rest combined:
A capability existing somewhere is not a capability this customer can have. When you do not know which of the three applies, say you will confirm. That sentence has never lost a deal.
Every limit here is a credibility asset. Say it plainly and move on.
"Do you have X?" has three possible true answers, and they are not the same answer. Confusing them is the most common way an accurate person makes an inaccurate claim.
Built means the capability exists somewhere. Code was written, a design was approved, a page describes it. That is engineering scope, not a promise.
Enabled means it is switched on for a particular customer or environment. Something can be fully built and deliberately not enabled.
Sold and supported means it is part of what SAGEN offers, with delivery and support behind it. This is the only one that answers a buying question.
The distinction matters because our own material spans all three. Repositories contain specifications and designs for work that has not shipped. The website describes marketing scope. A demonstration environment may show something a given customer would not have on day one.
None of that is dishonest. It becomes dishonest the moment someone reads a design document or a page and answers a buying question from it.
The safe answer when you are unsure is one sentence: "Let me confirm what is available for your situation and come back to you." It costs a day and it has never lost a deal. Claiming a capability that turns out not to exist costs the relationship.
This applies to services too. A framework mentioned in an internal scoping document is not the same as a service we currently offer.
A capability existing is not a capability available, and available is not sold.
Six pairs. Each shows a correct sentence and the incorrect version of the same claim. The contrast teaches the boundary faster than a rule does.
On remediation.
Correct: "We identify the exposure, explain the business impact, and define what evidence would prove it fixed. Your team or your IT provider makes the change and keeps rollback responsibility, and we verify the result."
Incorrect: "We will find your security problems and fix them for you."
On a clean findings list.
Correct: "They have no open findings, and collection is reporting as current, so this reflects today's state."
Incorrect: "They have no findings, so they are secure."
On a withheld score.
Correct: "There is no score because there is not enough evidence yet to produce one honestly. Here is what would produce it."
Incorrect: "They scored badly."
On an attack path.
Correct: "This describes a way an attacker could reach that system. It is not evidence that anyone did."
Incorrect: "An attacker got from here to the billing server."
On our AI.
Correct: "It explains the finding in business terms and suggests a response. A person decides, and it never changes the finding's state."
Incorrect: "The AI analyzes your environment and tells you what to do."
On availability.
Correct: "The product is available today. I will confirm the onboarding schedule with our delivery team."
Incorrect: "We can have you live by the end of the month."
The pattern across all six is the same. The incorrect version is shorter, sounds stronger, and claims something we cannot support. When a sentence feels satisfying to say, check it against these.
If it sounds better than the truth, it probably is not the truth.
One structure carries any conversation about a finding, an exposure, or a need. It works in a discovery call, a demonstration, or a review with an existing customer.
Most people do the first three well and stop. That is where the conversation feels finished and where the misunderstanding begins.
What was observed. State the fact without interpretation. What the evidence shows, and how current it is.
Why it matters. Move from the technical fact to the reason a person should care. Still specific, not yet dramatic.
Business impact. Which capability, process, or obligation is affected. This is the sentence a non-technical decision-maker will repeat to someone else.
Recommended next action. What should change, stated as an outcome rather than a prescribed configuration. The right implementation depends on their environment.
Responsible party. Who does it. Almost always the customer or their IT provider.
Validation and follow-up. What evidence would confirm it worked, and what happens if it does not.
The last two stages are what stop a conversation implying SAGEN performs the fix. Skip them and a customer leaves the room believing we will handle it, which is discovered later and badly.
The framework also protects against the opposite failure, which is a technically correct explanation nobody can act on. Stages three and four turn an observation into a decision.
Never stop at business impact. The last two stages are the ones that prevent a misunderstanding.
The questions prospects actually ask, and the honest answer to each. Read this before a first meeting.
| What they asked | The honest answer |
|---|---|
| "So you're a cybersecurity company?" | We build software and AI systems as well. Security is how we work, not our only offering |
| "Are we secure?" | A count of findings is not an answer. Give the state and how confident the evidence is |
| "Will you fix our vulnerabilities?" | We identify, explain, prioritize, and verify. Your team or IT provider implements |
| "Can you just close this finding?" | We do not set finding state. Here is what we can do instead |
| "Did someone actually break in?" | An attack path is hypothetical unless evidence says otherwise |
| "Nothing is showing, so we're fine?" | Only if collection is current. Check freshness before agreeing |
| "Why is there no score?" | Not enough evidence to produce one honestly. Here is what would produce it |
| "Can the carrier see our environment?" | No. They review a frozen package you approved, scoped and time-bound |
| "Is this a certification?" | No. We prepare organizations and support the process. An independent body certifies |
| "Which regulations apply to us?" | That is a legal question. We will route it to someone qualified |
| "Can our provider see this?" | Yes, where you granted it, in the same workspace |
| "Do you have feature X?" | Built, enabled, and sold are three different answers. Let me confirm |
| "How do we start?" | A focused engagement with agreed scope, before any large commitment |
Two patterns run through the table. Most of these questions ask for a guarantee we cannot give, and the honest answer persuades better than the one being fished for. Several ask us to draw a conclusion the evidence does not support, and agreeing damages the relationship later.
Add rows as real questions arrive.
The honest answer is almost always the more convincing one.
Five situations that come up repeatedly. Three lines each: what you are looking at, what it means, what you do.
A customer has no open findings
The list is empty, or much shorter than last time. Either nothing is wrong, or collection stopped and you are reading old data. Check freshness before saying anything. Then state the finding count and the freshness together, never one alone.
Collection is stale or unavailable
The workspace reports data that is no longer current. The last known state may still be true, and nobody can currently confirm it. Call it a monitoring gap, not a clean result. Say when it was last current, and treat restoring collection as the first action.
A score is missing
No score appears, or a value is labeled as last known. Evidence is insufficient to produce one honestly. This is deliberate restraint. Explain it as a strength, say what evidence would produce a score, and never describe it as a bad result.
A prospect asks about something you saw in a mockup or a document
They are describing a capability from a page, a design, or a demonstration. It may be built, enabled, or sold, and those are different answers. Say you will confirm what is available for their situation. Do not confirm it in the room.
A prospect asks you to commit to a go-live date
They want a date, and the meeting has momentum. Availability is settled. Scheduling depends on delivery and their environment. Say the product is available today and that you will confirm the schedule with delivery. Give a date only after delivery has given you one.
Every card ends the same way. Check, then say. Not the reverse.
How to present SAGEN in a first meeting, in order. Roughly ten minutes if nobody interrupts, and they will.
Never open with capabilities, never present the full offering to someone who described one problem, and never leave without a defined next step.
Their problem, our shape, the boundary, one small step.
How to demonstrate SAGEN Cyber Readiness, in the order that makes it land. Rehearse this from the text until you can run it without the screen.
Anything on our website marked illustrative uses fictional data. Never present it as a customer result.
Prove, not detect. That is the whole demonstration.