WEBVTT

00:00:00.000 --> 00:00:05.000
[AI-generated voice]

00:00:05.080 --> 00:00:08.520
Management wants to spend twenty-eight
thousand euros on a

00:00:08.520 --> 00:00:12.580
security tool. But two administrators share
the same account,

00:00:13.140 --> 00:00:16.260
and nobody has tested whether the backups can
restore

00:00:16.260 --> 00:00:19.460
the service. You have to decide where to
start.

00:00:20.100 --> 00:00:23.320
What would you approve first, and what
evidence would

00:00:23.320 --> 00:00:26.840
you need to defend your decision? Keep your
answer:

00:00:27.700 --> 00:00:29.280
we are going to test it with a case

00:00:29.280 --> 00:00:33.760
from the NormaPraxis campus. Bruma Cloud is a
fictional

00:00:33.760 --> 00:00:37.680
company that manages bookings for clinics. In
this exercise,

00:00:38.180 --> 00:00:42.020
your role is to guide a security decision. You

00:00:42.020 --> 00:00:44.160
do not need to guess which tool looks most

00:00:44.160 --> 00:00:48.200
advanced. You need to answer three questions:
what do

00:00:48.200 --> 00:00:51.480
we know, what could happen, and how would we

00:00:51.480 --> 00:00:55.480
check that a measure works? That is our route.

00:00:56.240 --> 00:00:58.740
By the end, you will have a way to

00:00:58.740 --> 00:01:03.640
structure your decision without inventing
probabilities or treating a

00:01:03.640 --> 00:01:06.980
purchase as proof that a problem has been
solved.

00:01:07.460 --> 00:01:10.380
Let us open the case file and separate facts

00:01:10.380 --> 00:01:11.380
from assumptions.

00:01:12.586 --> 00:01:16.106
The first piece of evidence identifies a
shared privileged

00:01:16.106 --> 00:01:21.426
account with no individual attribution. The
second records successful

00:01:21.426 --> 00:01:25.866
backup runs, but no recovery test. The third
explains

00:01:25.866 --> 00:01:28.846
that an eight-hour outage would prevent
bookings from being

00:01:28.846 --> 00:01:32.966
handled. Notice what we still do not know: the

00:01:32.966 --> 00:01:37.306
actual restoration time, the dependencies
needed to recover the

00:01:37.306 --> 00:01:41.406
service, and what other logs might help
investigate an

00:01:41.406 --> 00:01:47.746
administrative action. That missing
information matters. A rigorous decision

00:01:47.746 --> 00:01:51.726
makes uncertainty visible instead of filling
the gaps with

00:01:51.726 --> 00:01:56.006
figures nobody has measured. Think of an
emergency exit.

00:01:56.826 --> 00:01:59.966
Having a maintenance receipt is useful, but
the receipt

00:01:59.966 --> 00:02:02.426
alone does not prove that the door will open

00:02:02.426 --> 00:02:06.366
when needed. You must check the mechanism and
the

00:02:06.366 --> 00:02:12.146
route. Backups are similar: a successful run
provides information,

00:02:12.686 --> 00:02:16.926
but recovery capability requires testing the
restoration and the

00:02:16.926 --> 00:02:21.826
resulting service. The analogy has a limit:
data, applications

00:02:22.226 --> 00:02:26.426
and their dependencies also matter here. The
question is

00:02:26.426 --> 00:02:29.966
not simply whether a backup exists. It is what

00:02:29.966 --> 00:02:34.666
you can recover, under what conditions, and
with what

00:02:34.666 --> 00:02:35.106
result.

00:02:37.616 --> 00:02:41.756
Now turn the evidence into scenarios. First:
if the

00:02:41.756 --> 00:02:45.216
shared account is used for an improper change,
attributing

00:02:45.216 --> 00:02:48.056
the action to a person may be difficult,
depending

00:02:48.056 --> 00:02:52.396
on the available logs. Second: if the service
stops

00:02:52.396 --> 00:02:56.356
and restoration fails to work as expected,
booking operations

00:02:56.356 --> 00:02:59.796
may remain unavailable for longer than the
organisation can

00:02:59.796 --> 00:03:05.336
tolerate. These are different scenarios
requiring different measures. Before

00:03:05.336 --> 00:03:09.296
scoring them, agree on evaluation criteria and
who can

00:03:09.296 --> 00:03:14.656
accept the consequences. A matrix score helps
only when

00:03:14.656 --> 00:03:17.276
people understand what it means and where it
comes

00:03:17.276 --> 00:03:22.496
from. Let us return to the twenty-eight-
thousand-euro proposal. A

00:03:22.496 --> 00:03:26.576
monitoring tool can improve visibility and
detection, depending on

00:03:26.576 --> 00:03:29.996
its configuration and use. But its price does
not

00:03:29.996 --> 00:03:33.516
prove that it correctly attributes actions or
restores the

00:03:33.516 --> 00:03:37.016
service. Ask for a concrete link between the
capability

00:03:37.016 --> 00:03:39.336
you are buying and the risk you want to

00:03:39.336 --> 00:03:42.436
reduce. Ask what it covers, what depends on
other

00:03:42.436 --> 00:03:47.296
changes, and what would remain unresolved.
This exercise is

00:03:47.296 --> 00:03:51.176
not about rejecting technology. It is about
deciding what

00:03:51.176 --> 00:03:54.256
result you need and checking whether that
investment helps

00:03:54.256 --> 00:03:54.896
achieve it.

00:03:55.644 --> 00:03:59.004
Given this evidence, the best-supported option
in the exercise

00:03:59.004 --> 00:04:03.284
is to agree on criteria, assess the scenarios,
and

00:04:03.284 --> 00:04:08.064
prioritise identity and recovery. This may
involve reviewing privileged

00:04:08.064 --> 00:04:13.704
access, establishing individual attribution,
and planning a controlled restoration.

00:04:14.384 --> 00:04:19.184
The specific sequence depends on exposure,
consequences and available

00:04:19.184 --> 00:04:23.284
resources. We are not claiming that one
universal order

00:04:23.284 --> 00:04:26.984
applies to every company. We are justifying a
response

00:04:26.984 --> 00:04:31.244
to this case file. If new evidence emerged,
such

00:04:31.244 --> 00:04:35.124
as an immediate exposure or a critical
dependency, the

00:04:35.124 --> 00:04:38.504
priority would need to be reviewed and
explained. The

00:04:38.504 --> 00:04:43.024
decision needs a useful record. Describe the
scenario, identify

00:04:43.024 --> 00:04:48.024
its owner, and explain the evaluation
criteria. Then specify

00:04:48.024 --> 00:04:52.184
the action, the responsible person, the
deadline and the

00:04:52.184 --> 00:04:56.424
expected evidence. Add what risk will remain
and who

00:04:56.424 --> 00:05:01.044
has authority to accept it. For recovery, for
example,

00:05:01.584 --> 00:05:04.824
you could propose an isolated test with agreed
objectives

00:05:04.824 --> 00:05:09.564
and recorded timings and integrity checks.
This proposal must

00:05:09.564 --> 00:05:13.584
be adapted to the context. Avoid writing only
'improve

00:05:13.584 --> 00:05:17.224
backups': someone else must understand what
will be done

00:05:17.624 --> 00:05:19.484
and how they will know whether it worked.

00:05:20.204 --> 00:05:23.544
Now imagine that the team creates individual
accounts and

00:05:23.544 --> 00:05:27.124
approves a backup policy. They present
screenshots and propose

00:05:27.124 --> 00:05:31.044
closing the treatment. It seems we are
finished. However,

00:05:31.444 --> 00:05:33.644
the next step in the case adds two facts:

00:05:34.284 --> 00:05:37.904
the shared account remains available for
emergencies, and there

00:05:37.904 --> 00:05:42.624
is still no documented restoration. The
screenshots prove certain

00:05:42.624 --> 00:05:46.484
configuration changes; their use and
effectiveness still need checking.

00:05:46.484 --> 00:05:50.264
The question changes. It is no longer enough
to

00:05:50.264 --> 00:05:53.204
ask what was installed. We must ask what
behaviour

00:05:53.444 --> 00:05:56.724
was observed, using what sample and under what
conditions.

00:05:57.604 --> 00:06:01.184
For access, explain how you would verify
attribution of

00:06:01.184 --> 00:06:05.724
actions and control of emergency access. For
recovery, define

00:06:05.724 --> 00:06:09.564
an authorised, isolated test with data and
dependencies suited

00:06:09.564 --> 00:06:13.524
to the objective. Record the measured time,
verified integrity

00:06:13.524 --> 00:06:18.124
and deviations. Agreeing on success criteria
before execution prevents

00:06:18.124 --> 00:06:21.624
moving the goalposts when results arrive. If
the test

00:06:21.624 --> 00:06:25.644
fails, do not disguise the record. Preserve
the evidence,

00:06:26.144 --> 00:06:30.164
review the treatment, and decide again. An
uncomfortable result

00:06:30.164 --> 00:06:33.024
may be exactly the information you needed
before a

00:06:33.024 --> 00:06:33.584
real incident.

00:06:34.384 --> 00:06:36.944
Now you can return to management with an
explanation:

00:06:37.384 --> 00:06:39.804
this is the evidence, these are the
consequences we

00:06:39.804 --> 00:06:42.424
must evaluate, and these are the actions we
propose

00:06:42.424 --> 00:06:46.044
to verify. The purchase remains an option, but
it

00:06:46.044 --> 00:06:50.004
must demonstrate its contribution to the
objective. Always distinguish

00:06:50.004 --> 00:06:53.564
between a planned action, an executed action
and an

00:06:53.564 --> 00:06:57.264
action whose effectiveness has been verified.
This avoids marking

00:06:57.264 --> 00:07:01.184
a project green merely because tasks were
closed. Your

00:07:01.184 --> 00:07:05.644
proposal becomes easier to review when
assumptions, responsibilities and

00:07:05.644 --> 00:07:09.584
pending decisions remain visible. Return to
the answer you

00:07:09.584 --> 00:07:12.144
kept at the start. Did you choose a tool,

00:07:12.644 --> 00:07:15.864
accept the situation, or ask for criteria and
tests?

00:07:16.924 --> 00:07:19.504
What matters is whether you can explain your
choice

00:07:19.504 --> 00:07:22.664
using the available evidence and acknowledge
what is missing.

00:07:23.164 --> 00:07:26.124
In this case, we followed a simple chain:
evidence,

00:07:26.584 --> 00:07:31.864
scenario, criteria, treatment and
verification. Practising it helps identify

00:07:31.864 --> 00:07:35.824
answers that sound professional but cannot be
supported. It

00:07:35.824 --> 00:07:38.524
also helps improve a proposal when someone
asks a

00:07:38.524 --> 00:07:43.324
question you have not yet resolved. At
NormaPraxis, we

00:07:43.324 --> 00:07:48.564
practise these decisions through simulated
cases. Visit normapraxis.com and

00:07:48.564 --> 00:07:53.424
explore the campus. Start with one question:
what evidence

00:07:53.424 --> 00:07:55.544
would support your next decision?