CertiSigma Prudentia Suite exists for a precise professional moment: the moment in which a competent operator enters a privacy, cyber, organizational or evidentiary case and must put it in order without increasing the organization's information exposure. It is not the tool for a person who happens to stumble onto a problem. It is the kit for someone who must frame an intervention, facilitate a session, prepare a request, verify a dossier or support an organization during a delicate phase.

Organizational security lives on two levels. The first is the documentary level: policies, registers, procedures, appointments and declarations. They are necessary, and CertiSigma Prudentia Suite does not question them. The second level is evidence. Sooner or later someone asks for it: a client, an auditor, an authority, a partner, a governing body, a critical supplier or an internal function. At that point the question changes. It is no longer: "did we write this?". It becomes: "can we demonstrate it?". CertiSigma Prudentia Suite works on this second level.

The same applies during a critical event. Unauthorized access, human error, operational disruption, a badly shared document, a technical anomaly or possible data exposure are moments in which the organization must decide, document, communicate, preserve evidence and involve the right roles. Under pressure, even experienced operators need an orderly entry point: which perimeter to declare, which evidence to distinguish, which hypotheses must not become facts, and which information must not be transferred unnecessarily. CertiSigma Prudentia Suite provides that entry structure.

The method is simple: stop for a moment before the response. CertiSigma Prudentia Suite helps identify what is missing, test decisions, build non-identifying external requests when support is needed, and treat the dossier as a sensitive object when it is saved or transferred. It turns pressure into method, and doubt into an orderly work path.

CertiSigma Prudentia Suite makes one clear promise and maintains it throughout: it helps you see whether you can demonstrate what you declare, whether you can decide when something goes wrong, whether you can ask for help without exposing the real case, and whether you can protect the work produced instead of turning it into a new risk. It does not issue seals, scores or certifications, because its value is different and more concrete: it turns a declaration into a verification, a gap into a simulation, pressure into preparation and an exported file into a dossier to be protected.

1.1 Who it is for

CertiSigma Prudentia Suite speaks to competent operators: privacy and cyber consultants, DPOs, auditors, security leads, IT managers, compliance functions, tabletop exercise facilitators, institutional teams and professionals who are asked to bring order to a case. It is also useful for smaller organizations and less structured entities, especially when use is mediated by a facilitator, consultant or competent reference person. The suite assumes that the person using it already knows what it means to handle a real dossier: minimize, distinguish, document, avoid inference and avoid promising more than the evidence allows.

1.2 What you obtain

After an CertiSigma Prudentia Suite session, the operator has reusable material: an exposure and blind spot register with owners and operational consequences, one or more scenarios ready to exercise, the minutes and debrief of a tabletop exercise, an AI request formulated cautiously and in non-identifying terms, and a dossier that can also be exported in encrypted form. It is not reassurance. It is a verifiable working base.

CertiSigma Prudentia Suite identifies the CertiSigma operational layer for evidence, simulation and controlled action readiness.

It is an operational sequence, not a static register. First comes evidence: what can we demonstrate, what is missing, which proof is not available, which controls are not truly verifiable. Then comes simulation: what would happen if a gap became real pressure, an urgent request, an incident, a challenge or a regulatory doubt. Finally, readiness is built: the concrete ability to respond methodically, document decisions, involve the right roles and ask for support without exposing more than necessary.

The idea of stimulus remains central. Missing evidence is not just a field to complete: it is a signal that opens better questions. Why is it missing? Who should have owned it? Where should it have lived? Which process failed to produce it? Which decision would become fragile if that evidence were really needed? Every "we do not know" becomes a work item, not an embarrassment.

CertiSigma Prudentia Suite is therefore an operational gym: it turns a declaration into a verification, a gap into a simulation and pressure into preparation. This is the difference between having papers in order and knowing how to use them.

CertiSigma Prudentia Suite is operational documentation for someone who reaches the case with a responsibility already attached: to facilitate, verify, prepare, compare, ask for support or build a working base. The starting point is not the surprise of the problem, but the need to handle it well.

A privacy, cyber or evidentiary case rarely arrives clean. It may arrive as a clarification request, a client audit, a doubt about an access, an internal review, an exercise to prepare, an AI response to evaluate, a supplier to question, missing evidence or a dossier to compare. The operator must not only understand "what happened". The operator must also decide what can be said, what must remain abstract, what is proven, what is merely declared and which elements must not be handed to external tools or interlocutors.

CertiSigma Prudentia Suite is used at this entry stage. It does not replace the operator's experience: it disciplines it. It imposes a minimum order before the case is turned into a report, prompt, exercise, communication or follow-up. It helps avoid three typical errors: treating a declaration as evidence, treating a difference as an action performed, and treating a support request as permission to tell everything.

For this reason the suite remains local and offline. The work happens in the browser, with no server and no fetch. When the dossier must persist or travel, version 1.1 supports encrypted export/import and an encrypted local vault. Security here is not a technical ornament: it is part of the method. If the suite asks the operator to minimize what is said outside, it must also treat with caution what it produces inside.

The expected result is not a definitive answer. It is a cleaner entry: a readable dossier, a map of what is missing, a scenario that can be exercised and a non-identifying AI request. When a case evolves, the comparison between the current state and a previous save helps read the change without producing improper inferences.

CertiSigma Prudentia Suite works on three main entry points into the same organizational fragility, with an internal continuity function inside Prompt Builder.

The first moment is the gap. The organization discovers that it does not have a proof, does not know an owner, does not know where a log lives or which supplier controls a process. This is where Blindspot intervenes.

The second moment is proof under pressure. A simulated event leads the organization to decide, document, involve roles, distinguish facts and hypotheses, and understand what to communicate and what not to communicate. This is where Drill intervenes.

The third moment is the external request. When someone seeks help from an AI, a consultant, a lawyer, a technician or a supplier, the way the request is formulated matters. This is where Prompt Builder intervenes.

The evolution step is not a fourth standalone product. It lives inside Prompt Builder as a facilitated activity: Compare states compares the current compilation with a previous save of the same work, in order to distinguish documentary differences, new elements, removed elements and points requiring verification, without turning the delta into automatic proof that an action has been performed.

The three application pages answer the same underlying question: how can an uncertain situation be turned into an orderly path instead of improvisation?

Blindspot is the evidence-readiness module: it explores missing evidence, roles, controls and ownership, and makes them visible while there is still room to act.

It starts from normality, not from crisis. It may start from an evidence request, an internal review, a supplier check or a doubt about access, logs, backups, tokens, AI agents or opaque dependencies. It places the organization in front of what it would not be able to demonstrate today in an orderly way — and it does so in a safe context, without increasing informational pressure.

In Blindspot, "we do not know" is a valuable result. The blind spot emerges while there is still time to assign a responsible owner, look for proof, verify a process or turn the gap into an exercise. Blindspot shows where the organization would not be able to answer well: not so much because a policy is missing, but because evidence is unavailable, responsibility is unclear or reconstruction capacity is weak.

5.1 What Blindspot looks for

Blindspot looks for operational fragilities that become visible when someone asks for evidence, going beyond technical vulnerabilities alone.

A fragility may be evidence that should exist but cannot be found, an unclear owner, a dependency on an external supplier that was never mapped, a log that exists but cannot be exported, or a process that lives in a person's memory and not in a procedure. It may be a token that is still active, a forgotten account, an unmanaged OAuth connector, an AI agent with excessive permissions, or a backup that has never been tested through restore.

Often the blind spot is not an error but a grey area: everyone thinks someone else owns the evidence, and no one really knows. Blindspot brings these areas to the surface before they become incidents, challenges or rushed responses.

5.2 How Blindspot works

Blindspot works through guided questions. It leads the user into precise areas of attention — evidence, access, logs, suppliers, processes, responsibilities, data, AI tools, automation and business continuity — instead of asking for a free narrative.

The module collects an organizational snapshot: not a perfect picture, but a reasoning base on what we know, what we do not know, which controls we can demonstrate, which roles are clear and which dependencies remain opaque.

The answers produce findings. A finding is a question that has emerged with enough force to deserve attention; it is not a condemnation and not an automatic non-conformity. For example: "it is not clear who owns the evidence of the restore test"; or "the supplier manages a critical asset, but the contract does not clarify notification times and channels"; or "an AI or OAuth integration may continue to have access after an organizational change".

5.3 The output of Blindspot

The output of Blindspot is practical and actionable. It goes beyond the label "high risk" or "medium risk" and helps understand what is missing and what kind of action is needed.

A good output distinguishes four elements: the blind spot, the expected evidence, the missing or uncertain owner, and the possible operational consequence. If a log is missing, the issue is not only technical: during an event the organization will not be able to reconstruct well what happened. If an owner is missing, the issue is not only organizational: during an urgent request no one will know who must respond. If a clause or supplier channel is missing, the issue is not only contractual: during a crisis time will be lost.

Blindspot therefore produces material useful for an internal discussion, an improvement plan, a clarification request to a supplier or a Drill exercise.

5.4 Blindspot as a seed for Drill

The most powerful passage is that a blind spot becomes an exercise. When a gap is relevant enough, Blindspot turns it into a seed for Drill.

If Blindspot shows that it is unclear where access logs live, Drill can simulate a suspected unauthorized access. If an opaque dependency on a SaaS supplier emerges, Drill can simulate an urgent client request or an anomaly communicated by the supplier. If the issue concerns AI agents, tokens or automation, Drill can create a scenario in which the organization must understand who can revoke what, with which proof and in which timeframe.

This is the core of the Prudentia method: the gap does not remain a note; it becomes controlled pressure. The organization exercises before the pressure is real.

Drill exercises an organizational response and observes how the organization decides, documents and communicates. It may start from simulated scenarios, suitably abstracted real cases or a seed generated by Blindspot.

It is a tabletop exercise. It can also be used to reason on a real case, but it does not replace formal incident management, forensic analysis, legal assessments or internal procedures. The center is not acting out a crisis, but observing the method. Who decides? Who documents? Which evidence is preserved? Which roles are involved? When does the DPO enter? When does legal enter? When is the supplier asked? When is a communication premature? When is a hypothesis mistaken for a fact?

Drill starts from ready-made scenarios, internally built cases or a seed generated by Blindspot. A gap in evidence becomes a simulation on unauthorized access, unverified backups, an opaque supplier, a forgotten token, AI output improperly shared or an urgent client request.

6.1 Why simulation is needed

Many organizations discover their problems only during a real event, when the cost of learning is high: decisions are made under pressure, communication happens too early, the right people are involved too late, facts and hypotheses are confused, and the trace of who decided what is lost.

Drill moves this learning upstream from the event. It does not prevent every incident, but it reduces the probability that the organization responds in the worst possible way. The goal is not to prove that everyone is perfect: it is to observe where the process breaks — who does not know what to do, which evidence is missing, which channels are unclear, and which decisions remain suspended.

A successful exercise is not one in which everything runs smoothly, but one in which the right fragilities emerge without real damage.

6.2 The structure of a Drill scenario

A Drill scenario is built pressure, not a generic story.

It usually contains an initial event, a perimeter, roles, a set of constraints, data or assets potentially involved, incomplete information, complications and debrief questions. The facilitator can advance time — first hours, the day of the event, following days, final review — and each phase changes the questions.

At the start, the organization understands what is known and what is only suspected. Then it decides who coordinates, who documents, who preserves evidence, who speaks with the supplier, who evaluates privacy, who manages legal aspects and who informs management. Later, it evaluates whether and when to communicate, which checks are sufficient, which decisions must be justified and which information must not leave the room.

The strength of Drill is that it does not only ask: "what is the correct answer?". It asks: "how do you get there?".

6.3 Roles and decisions

In a real event, technical competence is not enough: clear roles are needed. An IT manager knows which logs to look at, but does not decide alone whether to communicate to a client. A DPO guides the privacy assessment, but needs technical facts. A lawyer assesses obligations and contracts, but must know what happened and what is only hypothesized. Management makes decisions, and should do so on a clear picture, not on confused impressions.

Drill makes this weave visible. It shows whether roles can really be activated, whether there is someone responsible for documentation, whether decisions are recorded, whether suppliers have defined channels and times, and whether internal communication is controlled. The exercise does not look for a culprit: it verifies whether the organizational system holds.

6.4 Evidence and debrief

The debrief is one of the most important aspects of Drill. Once the scenario is over, it does not only tell what happened; it asks what was missing.

Which evidence would have been needed? Who should have had it? How much time was lost understanding who decided? Which hypothesis was treated as a fact? Which communication would have been premature? Which supplier has a role that is not sufficiently governed? Which register, policy, log, contract or procedure failed under the test?

The debrief turns the exercise into improvement. This is what makes Drill a readiness tool, not just an interesting simulation.

6.5 Ready-made scenarios and extended scenarios

Drill starts from ready-made scenarios so that it can be operational immediately, and grows from there. Every organization has different surfaces: suppliers, data, roles, AI tools and pressures.

For this reason Drill is fed by Blindspot and, in future development, also by Prompt Builder. Blindspot provides blind spots; Prompt Builder can produce a structured trace to turn a request or doubt into a scenario. The result is a virtuous chain: a gap is seen, it is placed under pressure, the response is observed, and the process is improved.

Prompt Builder builds non-identifying requests to be submitted to an AI or LLM. The generated request goes to the AI; any later use of the output may involve a consultant, lawyer, technician, DPO, supplier, auditor, management or other interlocutor, but that reuse remains a decision of the operator.

It responds to a recurring professional need: even an expert operator may want to use an AI or LLM to obtain a grid, a draft, a consistency check or a list of cautions. The value of Prompt Builder is in the how: it helps clarify purpose, perimeter, hypotheses, available facts and necessary level of detail before submitting a request to the system.

Prompt Builder channels rather than forbids. It guides the operator to formulate a high-level, proportionate and non-identifying request that separates what is declared from what still needs verification. The principle is clear: stop, classify, build the request.

Prompt Builder gives you a reliable bridge toward external support, but the bridge first goes through the request to the AI/LLM. Formal assessments remain in the hands of those who must make them — lawyer, DPO, CISO, incident responder, technical consultant — and Prompt Builder makes them more effective by arriving with an already ordered question and with an output to be evaluated before any later use.

Prompt Builder offers two construction paths and one contextual function. Build the case is the ordinary path for building a non-identifying request. Go essential is the minimal path for avoiding an impulsive response. Compare states is not an autonomous entry point: it compares the current compilation with a previous save of the same case and generates a new prompt oriented to the delta.

CertiSigma Prudentia Suite may appear to be a suite with two movements: discovering blind spots with Blindspot and exercising them with Drill. In practice, however, a third need emerges, typical of specialist work: using external support, often AI/LLM support, without transferring the real case in an excessive way. Prompt Builder governs exactly that passage.

The value lies in how the request is formulated. In the initial phase it is easy to say too much, confuse facts and hypotheses, involve the wrong recipient, anticipate conclusions or turn a doubt into a case that has already been qualified. Prompt Builder slows down that passage and turns it into a readable and proportionate request.

The module builds requests that separate the need for support, the declared context, the limits of the request, hypotheses and missing information. It says to the recipient: help me reason by categories, without drawing definitive conclusions and without deducing elements that I have not declared. The result is that you ask for help while protecting the real case and still obtaining a useful response.

Prompt Builder offers a full path for those who have time to reason, and starts from the current case.

After the mode is selected, the module allows the user to load an ordinary saved case from a JSON file, only in the Build the case path. Go essential remains volatile: it does not load or save cases. Compare states loads only one previous case and compares it with the state currently compiled in the Build the case path. If the browser contains a locally saved structure, the module proposes to load it as a prefill in the block dedicated to the subject involved. The structure is a local browser convenience; the exported case is instead a self-contained file and also contains the subject structure, the scenario, the selections, the authorities, the notes and the generated prompt. Subsequent levels of the case are managed by saving new case files with names chosen by the user.

The structure/organization is a section of the current path. It may remain empty; when completed, it contains only stable or reusable categories: Europe / EU/EEA, Switzerland or Switzerland/Europe cross-border perimeter; reference country; organization type; organizational maturity; data, systems and assets normally processed or managed. These categories describe the subject in general and do not imply that the same assets are involved in the current case. Country is not inferred from the perimeter: a user who selects Europe chooses the EU/EEA country from a dropdown, or leaves the field on "Not indicated / to be determined". Switzerland is prefilled in the Swiss perimeter; in the cross-border perimeter the known side is prefilled as Switzerland and the European side remains selectable or unspecified.

The qualification of the current case is separate from the structure. This is where the nature of the main risk or exposure enters — privacy, cyber, business continuity, operational disruption, commercial or contractual risk, supply chain, reputation, AI, evidence or regulatory issues — together with any privacy qualification, the regulatory exposure declared for the case, the systems/channels/assets potentially involved, the types of information or content potentially involved and the roles, functions or controls already activated. This separation keeps what the organization is distinct from what is happening now, so that an episodic state is not saved as a permanent characteristic.

The authorities or institutional channels already activated are a later and separate section, because they describe the state of the case and not a stable characteristic of the organization. The catalogue is declarative: it shows some known references by country without automatically suggesting who to contact. If the user selects nothing, the prompt declares that no reports, notifications or interactions with authorities or institutional channels are indicated. Free notes enter the prompt with the formula "Also consider that:".

The module then asks for the state of the situation. Is it a real situation in progress? A doubt? A simulation? Preventive preparation? Post-event review? A request received from third parties? A case of possible improper use of external AI?

It then asks for the main problem: possible data breach, cyber anomaly, human error, improper sharing of a document, unauthorized or suspected unauthorized access, loss or unavailability of data, supplier issue, audit or evidence request, challenge, communication to prepare, doubt about AI use, or documents already entered into external AI.

Exclusive choices determine the branch. Multiple choices enrich the context. Conditional choices appear only when they are needed. The basic rule is even simpler: every selector starts empty and remains outside the prompt until the user declares it. An empty field does not mean "unknown" or "to be verified": it means that the field must not be cited, filled in or turned into a generic caution. In this way the prompt says only what you really know.

The module also asks for the recipient: external AI, authorized internal AI, lawyer, DPO, IT technician, supplier, management, auditor, insurer or consultant. This choice truly changes the generated text. A request for a lawyer is not a generic AI prompt; a request for a technician does not resemble a legal note; a request for a supplier asks cooperation and responsibility questions without exposing more than necessary.

Finally, the module asks for output and level of detail. These choices determine the format of the request, the tone, the methodological cautions and the structure of the expected response: they are concrete levers, not decoration.

Prompt Builder also offers a quick mode: Go essential, designed for someone under pressure who risks responding before having a sufficient picture.

The path is deliberately short: a few essential questions, centered on what happened and which support must be prepared. It does not open a list of exclusions and does not build scenarios: it produces a quick prompt or, when substantive input is missing, a minimum classification request.

Go essential has a quality that makes it reliable: it recognizes when it does not have enough information to answer, and says so. If the user selects nothing substantive, it does not invent an incident, does not assume a data breach and does not build an operational plan with snapshots, logs, notification and escalation. Instead, it produces a quick framing request.

This choice matters because many users will try the tool by leaving everything empty, precisely to see how it reacts. A tool that always replies with an operational plan looks blind to reality; Prompt Builder instead shows that it understands the difference between a case and an empty test. When there is no substantive input, the generated request asks the recipient not to build a management plan, but to help frame the situation, identify the essential questions and understand which signals would move the case toward operational checks.

Quick framing applies both in Go essential and in the full path: an empty or nearly empty request is treated for what it is, not as an operational case.

Compare states is Prompt Builder's facilitated activity for following an abstracted case that evolves over time. It is not a separate product and not a home entry point: it makes sense only when there is a currently compiled state and a previous save to import.

The flow starts from a previous ordinary JSON case file saved by Prompt Builder. The second term of the comparison is not another file, but the current state compiled in the module, even if it has not yet been saved. The comparison is allowed only between homogeneous cases, ordinary to ordinary; Go essential is not saved, loaded or compared in this function. The user can add manual notes, always abstract, on actions performed and findings that emerged.

The function maintains a precise discipline: a difference between two cases does not automatically mean that an action has been performed. If an element is no longer selected in the updated phase, it is treated as "no longer present" or "potentially overcome", not as closed. Only what the user declares in the notes is indicated as an action performed.

The result has two levels. The first is an internal comparison brief, to read what has changed, what remains open, what is new and what must not be considered automatically resolved. The second is a copyable external prompt, built according to the chosen objective.

The available objectives cover several use cases: neutral phase comparison, reconstruction of actions performed and next steps, delta stress test, updated operational plan, cautious communication and critical update of a previous AI response. The previous AI response is optional: when it is used, it is treated as text to be reassessed, not as truth, evidence or chronology.

This mode turns AI use from an isolated question into controlled progressive reasoning: it preserves the thread between initial state, response received, declared operations and updated state, instead of starting again from zero each time.

One of the principles that makes Prompt Builder reliable is anti-inference discipline. It guarantees that the prompt says only what you have declared, and nothing more.

The categories of the structure and of the problem orient the language; they do not prove what happened. If the structure indicates "healthcare subject", this does not imply that health data or patients are involved. If the perimeter is Europe / EU/EEA, Switzerland or cross-border, this does not imply a cross-border obligation or double notification. If the selected issue is "suspected unauthorized access", this does not imply confirmed access. If the user indicates a supplier as a possible factor, this does not imply that the supplier is responsible.

The generated request reminds the recipient not to complete the picture by plausibility. If a category is left empty, it does not appear in the prompt; if instead the user chooses Unknown or To be verified, that doubt enters as declared information. External AIs, and even consultants under pressure, tend to fill gaps: Prompt Builder prevents this by design.

It is a valuable rule because many wrong answers do not come from false information, but from an inference that is too fast. Prompt Builder does not ask for a conclusion: it provides a grid for reaching one correctly.

In the full path, Prompt Builder uses status, urgency and clarity of facts to determine an operational posture, not as mere descriptive labels. This is what makes the generated text adhere to the real situation.

The posture may be AI containment, active incident, post-event review, request received from third parties, preparation or diagnosis, ambiguity of facts, or default. Each changes the initial orientation, the priorities in the constraints and the next internal steps.

If possible improper use of external AI emerges, the priority is to contain further submissions and reconstruct by category what may have been shared. If the organization is in the first hours of a possible incident, the priority is to preserve evidence, identify who decides and suspend unnecessary external communications. If the case is a retrospective review, the priority is to reconstruct the timeline, distinguish what was known then from what is known now and identify what was missing. If it is preparation, the output works on gaps, ownership and scenarios, without sounding like an emergency.

In this way the module maintains fidelity between what it asks and what it produces. If the user indicates urgency and a real situation, the text changes. If the user declares preparation, the tone changes. If the facts are only suspected or contradictory, the module adds a constraint: treat the available elements as hypotheses to be confirmed, and do not act or communicate on unconfirmed elements.

One of the cases where Prompt Builder performs best is when external AI tools have already been used, or may have been used, in an ungoverned way.

Here the module goes beyond the generic "do not do it again" and offers an orderly reconstruction, without turning doubt into conclusion. Which tool or account was used? For what purpose? Was the output reused in documents, emails, tickets or decisions? Are there known policies? Who should be informed internally? Which containment measures are proportionate?

The module reconstructs the perimeter by categories and decisions, because the useful part is not to blame the user: it is to understand what happened, what is only a hypothesis and which checks are needed.

This is a central point for AI governance today. Organizations do not lose information only when they suffer incidents; they also lose it when, during a doubt or crisis, someone seeks help without method. Prompt Builder provides that method.

Prompt Builder and Drill remain distinct, and they collaborate. Prompt Builder builds orderly and non-identifying requests to ask for support or prepare checks. Drill remains the module dedicated to exercises and stress tests. The builder can clarify a case and pass a structured trace to Drill, while each tool keeps its own role.

Here too the anti-inference discipline applies: the structure is not the case. The categories of the structure and the categories of the case remain distinct, and the module produces a non-duplicated synthesis to avoid repetition and to avoid confusing what the organization is with what is actually involved in the scenario. This separation keeps the Blindspot → Drill → Prompt Builder chain controlled and readable.

CertiSigma Prudentia Suite looks at today's real surface, and this is where it differs from a traditional checklist.

Security is no longer only about servers, accounts and backups. There are software agents that may continue to act after an employee leaves. There are OAuth connectors linked to email, documents and CRM with broader permissions than necessary. There are prompts and logs that may contain personal data or credentials. There are AI tools used informally across departments, no-code automations that have become part of a process, forgotten tokens, help desks with broad powers, SaaS suppliers that hold essential parts of the activity. And there are new cases, such as an urgent request built with a cloned voice.

For this reason CertiSigma Prudentia Suite does not only ask whether an access policy exists. It asks who can really access, through which tools, with which integrations, with which logs, with which revocation capacity and with which available evidence. The surface has changed, and the way readiness is trained changes with it.

GDPR, NIS2, the Swiss data protection law, DORA, the AI Act, reporting obligations and ISO standards provide concrete reasons to be ready. CertiSigma Prudentia Suite uses them as a source of better questions, not as a script to recite.

The suite helps formulate the right questions: which data may be involved? Which roles must be heard? Which evidence is needed? Which communications are premature? Which contracts or agreements may be relevant? Which decisions must be documented? Formal qualifications — whether an organization is subject to a discipline, whether a notification obligation exists, whether an event is a data breach — remain where they belong, namely in legal, privacy, technical, forensic and incident response assessments. CertiSigma Prudentia Suite prepares them and makes them faster, by bringing already ordered questions to the table.

In CertiSigma Prudentia Suite, law is a source of questions: not an automatic label.

Version 1.1 adds a protection that was missing from the first form of the suite: the dossier can be exported and imported in encrypted form with a passphrase, and can be saved in an encrypted local vault in the browser.

This is consistent with the method. CertiSigma Prudentia Suite invites the operator not to say too much outside the perimeter; therefore the file produced by the suite must also be treated as a sensitive object. An export may contain blind spots, uncertain owners, debriefs, hypotheses, declared decisions, scenarios and AI requests. Even when abstract, it remains an operational dossier. If it travels, it must be closed. If it remains in the browser, it must not remain readable in cleartext.

The practical rule is simple: local, offline, encrypted when it persists or travels.

Encrypted export is the most important mode because it protects the transferable dossier: a file can move from one facilitator to another, from one browser to another, from one device to another, or be archived for follow-up. The suite does not save the passphrase and cannot recover it. If it is lost, the encrypted dossier cannot be reopened.

The encrypted local vault is a convenience for resuming work in the browser. In the dual-product bundle, vault keys are namespaced by product edition so the Italy/Switzerland and Europe/Switzerland editions do not overwrite each other. It is still not a collaborative feature and should not be used as a multi-session archive. The correct model is one active session at a time: if multiple tabs or copies save the same vault, the risk is not cryptographic but operational, namely overwriting more recent work.

Cleartext export remains possible where needed, but it must be a conscious choice. In CertiSigma Prudentia Suite there is no magic security: there is a clear distinction between open session, encrypted vault, encrypted export and cleartext export.

CertiSigma Prudentia Suite is deliberately sober. It works without a server, cloud platform, account or spectacular interface: it is a set of HTML, CSS and JavaScript files that work offline after the ZIP has been extracted.

This sobriety is part of the method, and reinforces its message. A tool that invites users not to upload data and documents elsewhere works without uploads, without connection and without dependency on external services. The consistency between what it says and what it is becomes a guarantee in itself.

CertiSigma Prudentia Suite is released by Ten Sigma Sagl under the Creative Commons Attribution 4.0 International licence — CC BY 4.0. The choice is deliberately permissive: anyone may copy, use, share, modify, adapt, translate, integrate, redistribute and build derivative works from CertiSigma Prudentia Suite, including for commercial purposes, without asking permission.

The minimum requirement is to keep the origin of the work visible. CertiSigma Prudentia Suite was created by Ten Sigma Sagl as an extension of the CertiSigma project. Modified versions must indicate that changes have been made and must not be presented as official versions of Ten Sigma Sagl or CertiSigma unless expressly authorized.

This openness values professional work by placing it in the right place. Those who adapt, facilitate, train on or verticalize CertiSigma Prudentia Suite may legitimately be paid: the value does not lie in blocking access to a file, but in turning an open method into something useful for a real organization, while keeping the origin of the method visible.

The following sections describe how the suite works technically, in a form also suitable for verbal explanation. They help explain why the project is built this way and how to put it to work immediately.

CertiSigma Prudentia Suite is deliberately simple to use. The user extracts the ZIP into a local folder, opens index.html with the browser and chooses one of the three main paths: Blindspot, Drill or Prompt Builder. Inside Prompt Builder the user can use Build the case or Go essential; Compare states remains available only as a contextual function when there is a current compilation to compare with a previous save. Alternatively, the user can open ESR-BLINDSPOT.html, ESR-DRILL.html or ESR-PROMPT-BUILDER.html directly.

A browser is enough. There is no need to install a server, no build step, no Python, Node, npm, fetch(), dynamic imports or internet connection. The package is designed to work also in simple environments, after extracting the ZIP, with local files opened in the browser.

The ZIP is only the distribution container: the real work happens on the extracted files, so it is advisable to extract the archive into a local folder and open the files from there.

Exported files may contain real weaknesses, organizational gaps, decisions, operational traces or sensitive information. The suite does not automatically upload data to external servers and has no Prudentia backend; outputs must nevertheless be treated as security reports. Any external attestations, such as the use of timestamping or proof-of-existence services, remain an explicit choice of the user.

This is the English European CertiSigma Prudentia Suite 1.1 release candidate. It is an autonomous product package in the CertiSigma line, with its own European perimeter and its own documentation. The Italian product has its own focus on Italy and Switzerland; the English product has its own European focus, with EU/EEA and Europe-facing cross-border cases, including Switzerland, as the operating perimeter. The suite version is declared in a dedicated field and the main modules are aligned with the 1.1 model: encrypted dossiers, local vault, encrypted export/import and Compare states as a contextual function of Prompt Builder. In Blindspot and Drill there is no autonomous Italy perimeter. In Prompt Builder, countries and authorities remain a declarative catalogue: Italy appears as an EU/EEA country with its main institutional channels, on the same level as the other countries present. Before stable use or distribution in real contexts, scenarios, generated texts, exports, browser behavior and adaptation to the organizational context should be verified.

The suite is an adaptable base by definition, not a complete package for every sector. Users may modify scenarios, models, mappings, texts, roles and categories, while maintaining the central principle: do not turn a checklist into reassurance, but use evidence as an operational stimulus.

CertiSigma Prudentia Suite is an offline HTML suite: no server to install, no platform to access, no Prudentia backend receiving data. The user extracts the ZIP into a local folder and opens index.html or one of the modules directly in the browser.

The suite works from file://, and this choice has precise practical consequences: no fetch(), no dynamic imports, no dependency on Node, npm, Python or a local web server. Data files and scenarios are loaded as classic scripts with <script src>. It is an essential architecture, consistent with the purpose of the project: to work also in simple contexts, without upload and without infrastructure.

The ZIP package is only the distribution container: the real work happens on the extracted files, so it is good practice to open the files from the extracted folder and not directly from the ZIP.

The package is composed of three main application pages, a home page, local documentation, shared assets, editable catalogues and a local validator for those who modify the system.

selector-root/
  index.html
  common/
    assets/
      css/
      js/
        esr-common.js
        esr-contract.js
      data/
        ESR-CANONICAL-CONTRACT.js
      img/
        esr-suite-logo.png

  europe-switzerland/
    index.html
    ESR-BLINDSPOT.html
    ESR-DRILL.html
    ESR-PROMPT-BUILDER.html
    LICENSE
    dev/
      validate.html
    assets/
      ESR_Suite.md
      documentation.html
      js/
        esr-crypto.js
        ESR-BLINDSPOT.js
        ESR-DRILL.js
        ESR-PROMPT-BUILDER.js
      data/
        ESR-AUTHORITIES-model.js
        ESR-BLINDSPOT-model.js
        ESR-DRILL-model.js
        ESR-INTEROP-model.js
        ESR-PROMPT-BUILDER-model.js
    scenarios/
      blindspot/
        ESR-BLINDSPOT-scenarios.js
      drill/
        ESR-DRILL-scenarios.js
        seeds/

index.html is the suite entry point. The three application pages remain autonomous and work from local file. The documentation lives in assets/ESR_Suite.md and in its viewer assets/documentation.html. The validator in dev/validate.html is not a fourth app: it is a maintenance tool for those who modify models, scenarios or mappings and want to check the coherence of the local build after the intervention.

The local library assets/js/esr-crypto.js contains the product-specific encryption text and the local encryption layer used by the modules for encrypted export/import and local vault. Shared neutral utilities, CSS, logo and the runtime contract are loaded from ../common/.

In the root selector bundle there is also a small common/ directory: it contains only neutral assets, shared plumbing and the canonical machine contract common/assets/data/ESR-CANONICAL-CONTRACT.js. It does not contain documentation, narrative examples or product copy.

The suite keeps models separate from application logic, so those who want to adapt it can work on content without touching code.

ESR-BLINDSPOT-model.js contains probes, preventive rules and fields for the organizational snapshot: it tells Blindspot which areas to explore and which blind spot categories to recognize.

ESR-DRILL-model.js contains vectors, data categories, complications, timings, scales, roles, presets, regulatory references, facilitator probes and clock steps: it allows Drill to build coherent exercises.

ESR-INTEROP-model.js is the contract between Blindspot and Drill. This is where the mappings live that turn a Blindspot finding into a Drill seed. This choice avoids keeping Drill IDs inside the Blindspot model and makes interoperability more controllable.

In the dual-product bundle, shared machine parts — sector IDs, vector IDs, data category IDs, complication IDs, timings, scales, clock steps, presets, required/allowed framework IDs and essential Blindspot → Drill mappings — are mirrored in the root contract common/assets/data/ESR-CANONICAL-CONTRACT.js and checked by common/assets/js/esr-contract.js. Local models remain the place for labels, descriptions and language/product specialization.

ESR-PROMPT-BUILDER-model.js contains taxonomies, recipients, categories, operational postures, next steps, handling of unclear external AI use and the other Prompt Builder components.

ESR-AUTHORITIES-model.js contains the declarative catalogue of countries and the best-known authorities/institutional channels used by Prompt Builder. The entries are not automatic recommendations: they indicate only what the user declares has already been activated or contacted.

Separating models from logic makes the suite adaptable: those who want to verticalize CertiSigma Prudentia Suite modify content and scenarios without rewriting the application.

Embedded scenarios live directly in JavaScript catalogues under scenarios/: scenarios/blindspot/ESR-BLINDSPOT-scenarios.js for Blindspot and scenarios/drill/ESR-DRILL-scenarios.js for Drill. They are not duplicated as courtesy TXT or JSON files.

This choice is consistent with the offline architecture: scenarios are loaded as classic scripts, without fetch() and without dynamic imports. Those who want to adapt the suite modify those catalogues without touching application logic.

The folder scenarios/drill/seeds/ is the natural destination for seeds generated by Blindspot when working on extracted files. The browser does not automatically write into that folder: it downloads the file, and the user can save it there to keep an ordered collection of seeds ready for Drill.

Blindspot combines user answers, probes and preventive rules. Probes are structured questions; rules transform combinations of answers into findings. The result is a reading of blind spots, offered as a reasoning base and not as an absolute diagnosis.

The module produces a register/plan and, where appropriate, a seed for Drill. The seed is not a long narrative document: it is a structured package with the minimum information needed to start a coherent scenario. Blindspot is therefore both a discovery module and a generator of exercise material.

Drill uses a scenario model that may include vectors, data, complications, roles, timing, scales, facilitator questions and debriefing criteria.

The module generates a session from presets, user selections or a seed imported from Blindspot. During the exercise, the user follows a clock, records decisions, observes evidence, produces minutes and uses the debrief to turn the scenario into corrective actions. Drill does not technically simulate an attack: it simulates the organization's capacity to respond to pressure.

Prompt Builder combines a declared structure, a current case state, an operational posture and a recipient. It does not always generate the same text: it changes orientation, constraints, structure and next steps according to the selections.

If substantive information is missing, it produces quick framing. If unclear use of external AI emerges, it produces specific questions about tool, purpose, account, timing, reused outputs and subsequent checks. If the recipient is a lawyer, it generates a different request than for an IT technician or a supplier. Drill remains a separate module.

The module always applies the same method: no definitive conclusion, no automatic inference from structure, and a clear distinction between facts, hypotheses and missing information. This is what makes the generated text reliable for the person who receives it.

Blindspot exports a seed ready for Drill. The seed carries, where available, the Blindspot finding ID, the source finding, the suggested Drill vector, the suggested Drill complication, a privacy/cyber trace, the jurisdiction and a suggested path under scenarios/drill/seeds/.

Drill imports this seed and starts a coherent scenario. If the seed contains a vector or complication that no longer exists in the Drill model, the app shows a warning and falls back to coherent generation. In this way a model update does not break the exercise: the seed guides, it does not command blindly.

The conceptual value is clear. A blind spot does not remain an annotation: it becomes an exercise. If proof on logs is missing, a scenario is built in which those logs are needed. If ownership is uncertain, a scenario is built in which someone must decide who responds. If a supplier is opaque, an urgent clarification request is simulated.

The modules export results in textual or structured formats. Blindspot produces registers, plans and seeds; Drill produces session minutes, material useful for debrief and structured traces for later management. Prompt Builder saves the reusable structure in the local browser as a prefill and exports the current case as a self-contained JSON; the generated prompt can also be exported as TXT. In Compare states mode, the JSON of the previous case is the basis for comparison with the currently compiled case, and the new output is an internal comparison brief plus an external prompt oriented to the chosen objective.

Persistent local saving uses an encrypted vault in localStorage: the browser stores an AES-GCM envelope protected by passphrase, not the cleartext dossier. The passphrase is not saved and cannot be recovered; on shared or public browsers it is still advisable to avoid the vault or clear local data after use.

Exports may contain real weaknesses, organizational gaps or sensitive operational traces. The suite works offline, and precisely for this reason outputs must be treated as security reports: care does not end with the absence of upload; it continues in the way the files are stored and shared.

The choice to work without server and without upload is consistent with the project's message before it is technical.

CertiSigma Prudentia Suite speaks about evidence, incidents, privacy and external requests, and remains a static local suite: it sends data nowhere and does not require a server to function. This is a readable guarantee, which anyone can verify by opening the files.

This architecture is a solid starting point, not a promise of absolute security. If a file is exported improperly, the risk remains; if the computer is compromised, offline execution is not enough; if the localStorage vault is used on a shared browser, the encrypted envelope may remain present and must be managed as sensitive content. The suite is honest about this: it offers a prudent method and an architecture consistent with that method, and leaves to the user the operational cautions that remain in the user's hands.

CertiSigma Prudentia Suite helps organizations stop before responding, see what is missing, exercise decisions and ask for support with method.

In an even shorter form:

When there is pressure, CertiSigma Prudentia Suite turns improvisation into method.

CertiSigma Prudentia Suite can be used on simulated cases, real cases or appropriately abstracted real cases. It does not produce audits, legal opinions, certifications, operational decisions, forensic reconstructions or definitive assessments. It helps distinguish what is known, declared, hypothesized, missing or to be verified; every decision remains with the competent professionals and functions.

CertiSigma Prudentia Suite is an operational gym: it brings gaps to the surface, trains decisions, improves questions, reduces improvisation and contains the risk of involuntary exposure. This is its job, and it does it well.

Formal assessments remain where they belong: audits, DPIAs, legal opinions, forensic analysis, incident response and determination of notification obligations. CertiSigma Prudentia Suite works upstream and makes them faster and more effective, by bringing already ordered questions and already prepared material to the table.

Organizational security becomes more mature when it stops coinciding with the idea of having everything in order and starts coinciding with the ability to look honestly at what is missing. This is exactly the capacity that CertiSigma Prudentia Suite trains.

CertiSigma Prudentia Suite — Evidence, Simulation, Readiness Released by Ten Sigma Sagl under the Creative Commons Attribution 4.0 International — CC BY 4.0 licence. You may copy, use, share, modify, adapt, translate, integrate, redistribute and build derivative works from CertiSigma Prudentia Suite, including for commercial purposes, without asking permission.

The only requirement is not to remove or obscure the origin of the work: CertiSigma Prudentia Suite was created by Ten Sigma Sagl as an extension of the CertiSigma project.

Suggested attribution: "Based on CertiSigma Prudentia Suite, created by Ten Sigma Sagl as an extension of the CertiSigma project, released under the CC BY 4.0 licence." If modified, indicate that changes were made. Modified versions must not be presented as official versions of Ten Sigma Sagl or CertiSigma unless expressly authorized.

Ten Sigma Sagl Swiss limited liability company Via Carzo 8, 6900 Paradiso, Canton Ticino, Switzerland Commercial Register of the Canton Ticino, entry dated 5 February 2015 IDE / UID: CHE-498.705.818

CC BY 4.0 licence: https://creativecommons.org/licenses/by/4.0/ Method genealogy: CertiSigma — https://certisigma.ch/

This English package is an autonomous European product package. The Italian package focuses on Italy and Switzerland, while this package uses European application logic and treats Italy only as one selectable country and authority catalogue entry among others. Blindspot and Drill therefore do not include a separate Italy perimeter.

The package follows a simple interoperability rule: visible labels may change across languages, while stable IDs and schema names remain shared. Exports should therefore be understood as language-portable data objects: the operator may see labels in English, Italian or another language, while the underlying JSON relies on canonical identifiers, module names and schema versions.

This means that future language or product packages should not translate IDs as if they were UI text. Labels can be localized; IDs, schema names and module contracts should remain stable unless a new schema version is intentionally defined. The purpose is to allow exports from different language packages to remain intelligible across versions and jurisdictions.

Evidential readiness Ability to demonstrate what the organization declares, with retrievable evidence, clear owners and documentable decisions.

Blind spot Area in which something should be known, verifiable or assigned to an owner, but is not sufficiently so.

Exposure Register Operational register of blind spots, missing evidence, uncertain owners and possible consequences.

Drill-ready A blind spot clear enough to become an exercise scenario.

Tabletop exercise A desk-based exercise in which the organization tests roles, decisions, communications and evidence without waiting for a real crisis.

Non-identifying request A request formulated without names, unnecessary details or references that make the real case recognizable.

Intended use of the output The context or interlocutor toward which the operator may use, after human evaluation, the material obtained from an AI response.

Anti-inference Discipline that prevents categories, clues or differences from being turned into unproven conclusions.

Compare states Contextual function of Prompt Builder that compares the current compilation with a previous save of the same work. It shows documentary or declarative differences, but does not prove by itself that an action has been performed.

Local dossier File or state exported from the suite. It may contain sensitive information even when it does not contain names.

Encrypted dossier Dossier protected by a passphrase through encrypted export or encrypted local vault.

Encrypted local vault Encrypted browser save, designed to resume work on the same workstation. It is not a collaborative feature.

Passphrase Phrase used to encrypt and decrypt a dossier. CertiSigma Prudentia Suite does not save it and cannot recover it.