The complete module page

Incidents & Continuity: who is in charge when the graduation goes off script

A radar that puts everything open across seven platform modules in a single list, coordinated incidents with severity from SEV1 to SEV4, an incident commander, status updates on a deadline and a bell notification when the SLA is breached, who is on call right now, incident cost, MTTA and MTTR calculated from milestones, critical processes with RTO, RPO and critical suppliers, contingency plans built from templates, step by step activation, crisis communications, blameless postmortems, actions from every module in a single list, exercises, readiness of upcoming events with a recorded go/no-go decision and weather forecast, a printable crisis kit, trend analysis and a maturity score.

This is the full reference for the module on a single page: the thirteen panel screens, the severity scale, the library of processes, plans and communications, the functional areas with every feature listed one by one, the design decisions that explain why the system refuses certain things, the boundaries with other modules and a glossary of incident response terms.

Talk to a specialistSee plans
  • 13panel screens, from the radar to the maturity score
  • 7modules read by the radar, without copying a single record
  • 12critical processes with suggested RTO and RPO
  • 12contingency plan templates, from the payment gateway to rain
  • 4severity levels with written criteria and SLA

Inside the module

13 screens, in the order the work happens

Four blocks in the panel menu. Response handles what is happening right now, continuity prepares the company for what could happen, learning makes sure the same problem does not come back, and configuration fits deadlines and safeguards to the pace of the company.

01

Response

What is on fire right now, who is in charge and what has already been done.

3 screens
  • DashboardOpen incidents by severity, status updates overdue against the SLA, severe incidents with no commander, who is on call right now, incident cost for the last 90 days, MTTA and MTTR, severe items on the radar with no incident, and plan coverage for critical processes.
  • RadarOpen issues from Event Production, Compliance, OHS, the field team, Support, Quality and recent failures of the bank payment routine in a single list, with normalized severity and a button to promote any of them to an incident.
  • IncidentsThe list and the incident room: triage, severity, commander and responders, current on call, time milestones, internal and external status updates, activated plan, communications, costs and the complete timeline. A personal data incident opens the privacy record in Compliance.
02

Continuity

Which processes bring the company to a halt, how fast they need to come back and what to do when they stop.

6 screens
  • Critical processesA ready made impact analysis: twelve processes with RTO, RPO, impact, owner, dependencies read from the platform, critical suppliers with backup and due diligence status, linked plan and last test. The list is filtered by the modules the company actually uses.
  • Contingency plansTemplates ready to apply and edit, a step editor organized by phase with owner and deadline, plus plan version, review and status.
  • ExercisesTabletop exercises, drills and technical tests of a plan, with scenario, participants, result and the gaps found.
  • Event readinessUpcoming events checked on the spot: staffing with unfilled slots, permits that expire before the date, open issues, linked incidents and whether the event plan was tested. Weather forecast on demand and the go/no-go decision saved with a snapshot of the checks.
  • On call & ContactsOn call schedule with primary and secondary, gaps in the schedule for the next 30 days and emergency contacts: public agency, insurer, supplier and internal, per process or per event.
  • Crisis KitPer process, plan or event, a printable page with the active plan and its steps, who to call, the on call roster, communication templates and the event checks. For the venue with no internet.
03

Learning

What the company learned from the incident, proof that the plan works and how much the response is improving.

3 screens
  • Postmortems & actionsA postmortem per incident with a draft built from the record itself, five whys, contributing factors and actions with owner and deadline. A tab brings actions from Continuity, Compliance and Quality into a single list.
  • Incident AnalysisMTTA and MTTR by month, percentage of SLA met, recurrence by category, source, event and supplier, and a day of week by hour map.
  • MaturityA 0 to 100 score across seven business continuity pillars, calculated from what is recorded, with the next steps that raise the score the most.
04

Configuration

The deadlines and safeguards the company adjusts, without rewriting the rule.

1 screen
  • ConfigurationAcknowledgment, status update and resolution SLAs per severity, a mandatory postmortem lock for SEV1 and SEV2, and the on call channel and contact.

The problem and the fix

What changes day to day for the people who respond when something goes wrong

The pain

The venue problem was logged in Event Production, the accident in OHS, the photographer who did not show up in the Team module and the urgent ticket in Support. Nobody could see all four at once.

With Partiu Formatura

The radar reads these sources live and shows everything that is open in a single list, with normalized severity. Nothing is copied: each record stays in the module that owns it.

The pain

The SEV1 incident started at 10 pm on a graduation Saturday, and the dashboard with the red status update had nobody watching it.

With Partiu Formatura

Every ten minutes the system checks open SEV1 and SEV2 incidents. An overdue acknowledgment or status update becomes a bell notification for administrators and the commander, once per breach, recorded in the timeline itself.

The pain

The plan said "call the on call lead", and nobody knew who that was that week or the phone number of the backup generator.

With Partiu Formatura

The on call schedule shows the current primary and secondary on the dashboard and in the incident room, and emergency contacts are kept per process and per event, with gaps in the schedule flagged before they happen.

The pain

The outdoor gala went ahead with an 80% chance of rain, and afterwards nobody remembered who decided to keep it or based on what.

With Partiu Formatura

Readiness shows the event weather forecast and points to the rain plan. The go, go with caveats or no-go decision is saved with the owner, the justification and a snapshot of the checks recalculated on the server at that moment.

The pain

Leadership asked how much the semester's incidents cost, and the answer was a guess.

With Partiu Formatura

Each incident records refunds, fines, overtime, replacement suppliers and lost revenue. The total shows in the incident room, and the dashboard adds up the last ninety days.

The pain

The caterer failed and the team found out on the spot that there was no backup on file, and that the supplier had failed due diligence.

With Partiu Formatura

Each critical process lists the suppliers behind it, the backup for each one and the due diligence status read live from Compliance.

The pain

Everyone assumed someone else was handling it, and the incident went an hour with nobody in charge.

With Partiu Formatura

Each incident has exactly one commander, and the dashboard highlights any SEV1 or SEV2 incident without one. The communications, technical, operations, supplier and observer roles are recorded in the incident room.

The pain

The graduation committee called three times asking for news, and the last update had been that morning.

With Partiu Formatura

Each severity has a status update deadline: every 30 minutes for SEV1, every 2 hours for SEV2. The delay is calculated in the database, on the same clock as the milestones, and shows up in red on the dashboard.

The pain

A severe incident was classified as minor so it would not draw attention.

With Partiu Formatura

Triage suggests the severity based on the answers: risk to life, personal data, event stopped, money at stake, manual workaround. Raising it requires nothing; recording it below the suggested level requires a reason, and every downgrade goes into the timeline.

The pain

The contingency plan lived in a PDF that nobody opened on the day the payment gateway went down.

With Partiu Formatura

The plan is activated inside the incident and becomes a step by step checklist, with phase, owner and deadline. Marking a step as not applicable requires a written reason.

The pain

Nobody could say how long billing could stay down, or what it depended on.

With Partiu Formatura

Critical processes come with RTO and RPO already suggested for a graduation company, and dependencies are read from the configuration: payment gateway enabled, WhatsApp connected, storage, staffing and permits.

The pain

The same problem came back at the next event, because the meeting after the incident turned into a hunt for someone to blame.

With Partiu Formatura

A postmortem can only be published with a summary, what failed, at least one why and a root cause written as a sentence. A person's name on its own is not accepted. SEV1 incidents only close with a published postmortem.

The pain

The day before the graduation, the team found out two people were missing from the staffing plan and the venue permit expired one day earlier.

With Partiu Formatura

Readiness checks each event in the coming days against staffing, permits, open issues, incidents and the event plan, and sorts them from critical down to on track.

The pain

The message to graduates went out with the wrong estimate and a template field left blank.

With Partiu Formatura

The communication is drafted from the template using the incident data. Any placeholder the system cannot fill stays visible, and the record refuses text with leftover placeholders.

How it works

The path of an incident, from the first report to the action that prevents the next one

  1. 1

    The issue shows up

    Someone logs the problem in the usual module: Event Production, OHS, Team, Support. The radar shows the open issue alongside the others, without anyone having to copy it.

  2. 2

    It becomes a coordinated incident

    The issue is promoted, and the incident keeps only a reference to its source. Triage suggests the severity, the INC-YYYY-NNNN code is generated on the server and the detection milestone is recorded.

  3. 3

    Command takes over

    The commander is assigned, responders get roles, the contingency plan for the affected process is activated and its steps become a checklist inside the incident room.

  4. 4

    Information flows on time

    Internal and external status updates are published within the severity SLA, and communications to graduates, the graduation committee, staff or suppliers come from templates filled in with the incident data.

  5. 5

    Milestones keep time

    Acknowledged, contained, resolved and closed, each recorded on the database clock. They produce MTTA, MTTR and the delay of every status update.

  6. 6

    Learning closes the loop

    The blameless postmortem records the root cause and contributing factors, corrective actions get an owner and a deadline, and the next exercise proves that the revised plan works.

How the system behaves

17 decisions that explain everything else

They explain why the system sometimes does not do what you might expect, and why that is intentional.

The radar reads, it does not copy

There are at least seven modules where the platform records problems, each with the right owner. Copying everything into a new table would create a second version that drifts on the first update. The radar queries each source live and the incident keeps only the reference.

The module opens with data on screen

Critical processes, plan templates and communications ship ready in the code, and dependencies are read from the configuration the company already has. A module that demands setup before showing the first row stays empty forever.

Severity is a rule, not an opinion

The criteria for each level are written down and triage suggests the level from the answers. Raising it is free. Lowering it requires a reason and stays in the timeline, because an incident downgraded to avoid attention is exactly the one that needs attention most.

The clock belongs to the database

Incident milestones are recorded with the database server time, and SLA delays are calculated in the same place. Time coming from the browser depends on each device clock, and then MTTR ends up measuring the phone of whoever clicked.

Only one commander

Two commanders is the same as none: each one waits for the other to decide. The server refuses to assign more than one, and the other roles exist to split the work without splitting command.

Activation copies the steps

The plan can be improved the next day, but the postmortem needs to read the plan as it was during the incident. That is why steps are copied at activation and later edits do not rewrite what was executed.

A person is not a root cause

A name alone in the root cause field is where the investigation starts, not where it ends. A postmortem is only published with the cause written as a sentence and with what failed, because blaming someone does not stop the same problem from coming back with another person.

Communications do not invent values

Placeholders the incident cannot fill stay visible in the text, and the record refuses a message with leftover placeholders. An invented estimate in a message to graduates costs more than a blank field someone catches before sending.

The module does not send messages

The communication is drafted, reviewed, sent through the usual channel and recorded here. Automatic sending will come when there is one off messaging with reusable auditing, and until then the record shows who sent what, to whom and when.

Unknown is an honest answer

When there is not enough data to assess a dependency or a readiness item, the status shows as unknown, not ok. The screen that pretends everything is fine is the one that lets the event fall apart.

Configuring means adjusting, not rewriting

The company stores only what changed from the default SLA and process settings. If the default rule improves in an update, anyone who did not touch it gets the improvement, and anyone who did keeps their own value.

An untested plan is an assumption

A completed exercise requires a result, and any result other than passed requires the gaps written out. Event readiness considers whether the event plan was tested in the last twelve months, not just whether it exists.

Alert once, and again only if it runs late again

The same alert repeated every ten minutes teaches people to mute the bell. Each breach is announced once, and a new status update opens a new window: whoever runs late again gets alerted again. The control lives in the incident timeline, where the history shows when the alert went out.

The decision keeps what was known at the time

After the event, the debate is always about what could have been known beforehand. That is why go/no-go checks are recalculated on the server the moment the decision is saved and stay frozen, without accepting the version that came from the screen.

Weather forecast only when someone asks

The readiness list cannot depend on an external service to open. The forecast is checked event by event, only for the next seven days, with cache and timeout, and the city used shows up for the reader to double check.

A crisis plan has to work without internet

The most serious incident at an event usually happens in a venue with poor signal. The crisis kit brings plan, contacts, on call and communications together on a page made to print beforehand, not to open during.

Supplier status is read, not copied

Critical supplier due diligence stays in Compliance and is read live. A copy here would stay approved forever, even after the supplier landed on a sanction list.

The boundaries

Where incident response ends and the rest of the system begins

The module never keeps a second copy of anything. It reads what already exists and returns what it produced through the same path as the rest of the platform.

Event Operations Room

Event day problems are still logged in Event Production. The radar shows what is open there, and readiness matches open issues with the event before it starts.

Compliance Control

Integrity incidents stay in Compliance, with investigation and remediation. The radar reads those incidents and serious monitoring alerts, a postmortem action can point to the action there, and a personal data incident opens the privacy record where the ANPD 3 business day deadline runs. Critical supplier due diligence also comes from there.

Finance

Bank payment routine failures show up on the radar while recent, and the graduate billing process keeps the payment gateway as a dependency read from the configuration.

Occupational Health and Safety

Accidents and near misses stay in OHS, which owns the CAT (workplace accident report). The radar shows only the beginning of the description, and the details stay under OHS permissions.

Quality and Conformity

Nonconformities and complaints stay in Quality. They appear on the radar while open, and a postmortem corrective action can reference the quality system action.

Events and Tickets

Readiness reads upcoming events, the field team staffing and the permits linked to each one. The incident can be linked to the affected event and class.

Communication

The crisis communication is drafted here and sent through the usual channels. The send record stays in the incident and counts as a status update toward the severity deadline.

Governance

Who sees what, and what runs without anyone asking

4 separate permissions

Checked on screen and in the API. Nothing in the module is sensitive by nature, so it does not use strict permissions; the details of each issue remain under the permissions of the source module.

  • ViewDashboard, radar, incident list, critical processes and plans, read only.
  • IncidentsOpen incidents, promote from the radar, publish status updates, change severity, mark milestones, enter costs, record the go/no-go decision and close.
  • PlansAdjust critical processes and their suppliers, apply templates, edit contingency plans, record exercises and maintain on call and emergency contacts.
  • ConfigurationSLAs per severity, postmortem locks and on call channel.

What gets calculated without anyone asking

There is no setup to keep up to date. Every screen calculates on open, from what the platform already records, and a single scheduled routine takes care of alerting SLA breaches to people who are not watching.

  • Radar readingIssue sources are queried every time the screen opens, with the database structure checked first, and one source being down does not take the others with it.
  • Suggested severityTriage answers become a severity level using the criteria in the code, stored alongside the chosen level.
  • Status update delayTime since the last update is compared to the severity SLA in SQL, and the overdue incident moves up on the dashboard.
  • MTTA and MTTRAverage time from detection to acknowledgment and to resolution, per severity, over the last ninety days.
  • Process dependenciesPayment gateway, WhatsApp, storage, staffing, permits and integrations read from the configuration every time the screen opens.
  • Event readinessEach event in the chosen window is checked against staffing, permits, issues, incidents and tested plan, and gets the worst status found.
  • Postmortem draftThe timeline and incident data fill in the draft when the postmortem is opened.
  • SLA breach alertEvery ten minutes, SEV1 and SEV2 incidents with an overdue acknowledgment or status update trigger a bell alert, once per breach.
  • Current on callWho is primary and secondary right now, and where the schedule for the next 30 days is uncovered.
  • Maturity scoreThe seven pillars recalculated on every open, from plans, exercises, incidents, postmortems, on call and readiness.
  • Trend and recurrenceMTTA, MTTR, SLA met and repetition by category, source, event and supplier aggregated on the spot.
  • Incident costSum of costs entered over the last ninety days, on the dashboard.

In practice

5 everyday situations, from problem to result

01

The photographer who did not show up at the ceremony

The scenario

One hour before the ceremony, the lead photographer had not checked in. The coordinators found out through the group chat, and three people started calling different backups at the same time.

With the system

The team issue appeared on the radar and was promoted to a SEV1 incident, because the event was only hours away. A commander was assigned, the staff shortage plan was activated, and the steps to call the professional, bring in the backup and redistribute coverage became a checklist with deadlines.

The result

A backup arrived before the class walked in, the graduation committee was notified through the template, and the postmortem identified the outdated backup list as the cause, with an action to review the list before every event.

02

The payment gateway that stopped on due date

The scenario

On the day with the highest boleto volume of the month, PIX stopped generating. Finance noticed from the complaints and nobody knew whether to suspend automatic billing.

With the system

The incident was opened as SEV1, because billing was down with no workaround. The gateway plan said to suspend automatic sending, open a ticket with the provider and notify the graduation committee, and status updates went out every 30 minutes with the delay visible on the dashboard.

The result

Payments for the period were reprocessed the next day, MTTR was recorded, and the billing process got an RTO adjusted to the reality of the company.

03

The week before that showed what was missing

The scenario

On Monday, the production team opened readiness for the events of the week. A Saturday gala looked in order on the calendar.

With the system

The check showed two staffing slots still with no one assigned and the venue inspection report expiring on Friday, one day before the event. The event execution plan existed, but had never been tested.

The result

The slots were filled on Tuesday, the report renewed on Wednesday, and a tabletop exercise was scheduled with the team before the next gala.

04

The photo link that went public

The scenario

A graduate reported being able to open another class's gallery through a shared link. The first reaction was to delete the link and move on.

With the system

Triage flagged personal data exposure, and the incident started as SEV1. The data leak plan said to bring in the data protection officer, preserve evidence before cleaning up and identify which data subjects were affected, and the notice to data subjects came from the template with its fields reviewed.

The result

The exposure was contained with the records preserved, the assessment of notifying the ANPD was documented on time through the privacy record opened from the incident room itself, and the postmortem could not be published until it had a root cause beyond the name of whoever created the link.

05

The garden gala with rain in the forecast

The scenario

On Thursday, Saturday's graduation at an outdoor venue was still marked as on track. The coordinators only checked the forecast on their phones, each in a different app.

With the system

In readiness, the forecast for the day showed a 75% chance of rain and pointed to the outdoor event rain plan, which was active. Leadership recorded go with caveats, justified by setting up a tent, and the decision was saved with the checks from that moment.

The result

The tent was booked on Friday, the supplier contact went into the printed crisis kit for the event and, when it rained at 9 pm, the team already knew what to do.

Glossary

Incident response terms, explained

If you came here looking for the industry terms of incident management and business continuity, this is what each of them means inside the module.

IncidentCoordinated response
A problem promoted to a coordinated response, with severity, commander, milestones and timeline. Not every issue becomes an incident.
SEV1 to SEV4Severity levels
The incident severity scale, from critical to low, with written criteria and a response deadline for each level.
CommanderIncident commander
The person who makes decisions during the incident. There is only one, and the other roles split the work without splitting command.
Status updateSituation report
The situation update published during the incident, internal or public facing, on a deadline set by the severity.
MTTAMean time to acknowledge
How long, on average, passes between detecting an incident and acknowledging it.
MTTRMean time to resolve
How long, on average, passes between detecting an incident and resolving it.
SLAResponse deadline
The maximum time to acknowledge, update and resolve each severity. Defaults come from the code and the company adjusts them.
BIABusiness impact analysis
The assessment of which processes bring the company to a halt and how fast they need to come back. Here it is the critical processes screen.
RTORecovery time objective
How quickly the process needs to be working again after it stops.
RPORecovery point objective
How much information the company is willing to lose when the process stops. Zero means none.
Contingency planRunbook
The steps by phase that the team follows when a process stops, with owner and deadline.
PostmortemBlameless postmortem
The account of the incident after it is resolved, with root cause, factors and actions, written without looking for someone to blame.
Five whys5 whys
The technique of asking why several times in a row until you reach the cause that, once fixed, prevents it from happening again.
Tabletop exercisePlan rehearsal
A rehearsal of a plan with the team gathered to talk through the scenario, without actually executing it.
Business continuityContinuity planning
Preparing so that essential processes keep running, or come back within the agreed time, when something gets out of control.
On callOn-call rotation
The person scheduled to respond when something happens after hours, with a primary and a secondary.
Go/No-GoProceed decision
The recorded decision to hold the event, hold it with caveats or not hold it, made with the readiness checks in view.
Crisis kitPrintable runbook
The plan, contacts and communications gathered on one page to print and take to the event.
Critical supplierSingle point of failure
The supplier without whom a critical process stops, and who therefore needs a defined backup.
MaturityBusiness continuity maturity
The score that says how prepared the company is, measured on what it recorded, not on a self assessment.

FAQ

The questions that come up when evaluating the module

Does the module replace issue logging in Event Production, OHS or Support?

No. Each issue is still logged in the module that owns it. The radar reads those records live, and only what needs a coordinated response is promoted to an incident, which keeps a reference to the source.

Do I need to set up processes and plans before using it?

No. The twelve critical processes, twelve plan templates and seven communication templates come ready, and dependencies are read from the platform configuration. The company adjusts whatever is different in its own reality.

Does the system send the message to graduates on its own?

No. The communication is drafted from the template with the incident data, a person reviews it, sends it through the usual channel and records the send. That record counts as a status update toward the severity deadline.

Can I change the deadlines for each severity?

You can adjust the acknowledgment, status update and resolution deadlines, within limits that keep the order between levels. The criteria for each severity remain the ones in the code.

Does every incident need a postmortem?

SEV1 only closes with a published postmortem, and the company can turn on the same lock for SEV2. Other incidents can have a postmortem when it makes sense.

Does the module monitor whether the platform is up?

No. Technical uptime monitoring lives in a different tool. This module handles response coordination and company preparedness, including the plan for when the app or the panel goes down.

Does it work without the OHS, Compliance or Quality modules?

Yes. The radar shows the sources available in the environment and flags which ones are not, without breaking the screen. The same goes for dependencies and event readiness.

Is there an on call rotation with automatic calls?

There is an on call schedule, with primary and secondary per period, who is on call right now and gaps in the schedule. Automatic calls, no: the SLA breach alert arrives through the bell, and the phone number of whoever is scheduled shows on the dashboard, in the incident room and in the crisis kit.

Does the system alert when an incident deadline is breached and nobody is watching?

Yes. Every ten minutes it checks open SEV1 and SEV2 incidents and sends a bell alert to administrators and the commander when acknowledgment or a status update is overdue, once per breach.

Does the weather forecast need any setup?

No. It uses an open service with no key and is checked on demand for events in the next seven days. The city comes from the record or the event venue text, and the screen shows which one was used.

Keep exploring

The modules that work alongside this one

Event Operations Room

The event day dashboard, with attendance, staff, checklist and issues logged while the party is happening.

View page

Compliance Control

Integrity program, incidents with remediation and an ethics hotline, the governance that sits right next to incident response.

View page

Quality and Conformity

Nonconformities, corrective actions and effectiveness checks, the source of the actions a postmortem can reference.

View page

A plan that exists before the problem, and a commander who shows up when it arrives

We can open the radar with issues from your operation, simulate an event day incident, activate a ready made plan right in front of you and talk about the rollout path for your reality.

Talk to a specialistSee plans