WEBVTT

1
00:00:00.630 --> 00:00:12.902
Welcome to NxSAM training. This module covers Deviations and Risk Acceptance: the formal record that someone has decided, deliberately, not to fix something yet.

2
00:00:13.185 --> 00:00:32.278
Every organisation does this. Some findings cannot be fixed on the timeline the S L A wants - a vendor has no patch, a change window is months away, or the fix costs more than the risk. The question is never whether it happens, only whether it is recorded.

3
00:00:32.879 --> 00:00:44.529
An unrecorded decision looks exactly like negligence six months later. A recorded one is a risk decision with a name, a reason, and a date attached to it.

4
00:00:45.143 --> 00:00:51.227
There are two kinds of acceptance, and the difference decides everything else in this module.

5
00:00:51.819 --> 00:01:02.629
A permanent acceptance says this will not be fixed, and that is the settled position. A temporary acceptance says not yet, and carries an end date.

6
00:01:03.239 --> 00:01:17.244
Only a temporary acceptance can expire, because only a temporary one has a date to expire against. Everything the product does automatically in this module follows from that single fact.

7
00:01:17.877 --> 00:01:27.222
The management list is where they all live, and its columns are unusually well-chosen - two of them exist purely to stop this module going wrong.

8
00:01:27.491 --> 00:01:45.717
A risk acceptance identifier and its details, and under the identifier whether this is a first request or a renewal. Then which kinds of finding it covers. The initiator, who raised it. Approved By, once somebody has.

9
00:01:46.317 --> 00:01:57.968
Then Pending On, which names whoever it is currently waiting for. Then the end date. Then Auto Reject End Date. Then its status.

10
00:01:58.586 --> 00:02:13.351
Pending On is the column that makes this module workable. A request that has not moved is not a mystery - the screen names the person it is sitting with, so chasing it is a matter of reading a row rather than an investigation.

11
00:02:13.936 --> 00:02:22.586
And Auto Reject End Date is the one to understand before you raise anything, because it is a deadline the product enforces on its own.

12
00:02:23.175 --> 00:02:28.847
Here is the rule that catches organisations out, and it is worth saying twice.

13
00:02:29.464 --> 00:02:44.760
A request that is still pending approval when its own end date passes is automatically rejected. Nobody rejects it. No one is asked to decide. The date passes overnight, and the request dies.

14
00:02:45.397 --> 00:02:57.934
Which means the risk it was covering quietly goes back to being an ordinary open finding, still counted, still ageing against its service level - and the person who raised it is not prompted again.

15
00:02:58.526 --> 00:03:11.737
So a deviation request is not a place to park something. If approvals in your organisation take three weeks, an end date two weeks out will be auto-rejected before anybody has looked at it.

16
00:03:12.353 --> 00:03:25.540
That is exactly why the date is a column rather than something buried in a form. Read it every time you open the list, work the ones closest to their date, and this failure never happens to you.

17
00:03:26.147 --> 00:03:32.348
Raising one starts from a finding, and there are two entry points that are not the same thing.

18
00:03:32.926 --> 00:03:50.286
Raise New Risk Acceptance is a first request. Renew Risk Acceptance continues one that has run out. The product treats them as genuinely different, and so should you - renewing is a decision to keep accepting a risk you have now lived with.

19
00:03:50.890 --> 00:03:55.031
Opening one shows what a request actually asks for.

20
00:03:55.607 --> 00:04:14.363
Four things make a request that survives review. What the risk actually is, in business terms rather than technical ones. Why it cannot be remediated now. What compensating controls reduce it meanwhile. And when it will be revisited.

21
00:04:14.980 --> 00:04:29.511
The compensating control is the one most often left thin, and it is the one an auditor reads first. A deviation with no compensating control is not a risk decision; it is a note saying the risk was noticed.

22
00:04:30.083 --> 00:04:35.327
Deviation Type is the field that decides whether this expires at all.

23
00:04:35.924 --> 00:04:49.658
Time bound, and it comes back to you on a date you chose. Permanent, and it does not - which is occasionally the honest answer, and much more often the one chosen because nobody wanted to pick a date.

24
00:04:50.267 --> 00:05:03.119
Keep the period short. It is tempting to ask for a long window to avoid coming back, but a short period renewed deliberately is a far better record than a long one nobody revisits.

25
00:05:03.701 --> 00:05:17.487
And notice the two steps at the top. The detail you have just seen is step one; step two attaches the actual findings this acceptance covers, and it does not open until step one has been saved.

26
00:05:18.116 --> 00:05:31.085
That order is deliberate. It means you cannot accept a risk without first writing down why - the justification exists before the list of things it excuses, rather than after.

27
00:05:31.717 --> 00:05:42.721
Closing it changes nothing. A request exists only once it has been saved, and a draft that was never saved is not a risk anybody has accepted.

28
00:05:43.352 --> 00:05:53.852
Download as a spreadsheet takes the whole population out - which is how this list becomes a paper for a risk committee rather than a screen somebody has to be shown.

29
00:05:54.458 --> 00:06:04.210
Where a request goes for approval is not fixed. It is configured, and the configuration is more capable than most people realise.

30
00:06:04.830 --> 00:06:14.971
Three selectors sit above the table, and together they choose which approval chain you are editing. So this is a matrix rather than a single route.

31
00:06:15.581 --> 00:06:28.886
The first is whether the finding belongs to a project or not. The second is the one worth pausing on: whether this is a new risk acceptance or a renewal. And the third is the risk level.

32
00:06:29.481 --> 00:06:48.404
That second axis lets you say something sensible about governance. A first request at low severity might need one approver. The third renewal of a critical finding - something your organisation has now been carrying for a year - can require considerably more.

33
00:06:49.023 --> 00:06:53.785
And the third axis is severity, which is the one people expect.

34
00:06:54.361 --> 00:07:11.326
Five levels, and the chain below the selectors belongs to the one that is ticked. Change it and you are editing a different chain entirely - which is the whole point, and also the thing most easily missed, because the table does not move when you look away from it.

35
00:07:11.956 --> 00:07:21.135
Which is the right way round. The decision that deserves scrutiny is rarely the first one; it is the one that quietly repeats.

36
00:07:21.737 --> 00:07:37.899
The chain itself is four levels here - a security lead, a department head, a vice president and the chief information security officer - and each level names a designation rather than a person, so the chain survives somebody changing jobs.

37
00:07:38.480 --> 00:07:47.680
Levels are sequential, so a request moves through them in order - which is why Pending On always has a single answer rather than a committee.

38
00:07:48.296 --> 00:08:03.789
Set the approver by relationship rather than by naming individuals wherever you can. An approval chain that names people breaks the first time somebody changes job, and it breaks silently - requests simply stop moving.

39
00:08:04.360 --> 00:08:10.897
Designations are configured alongside, which is what those relationships are drawn from.

40
00:08:11.500 --> 00:08:18.446
The request form itself is yours to shape, which matters more here than anywhere else in the product.

41
00:08:19.066 --> 00:08:35.946
Six properties are configured here, and each one is a field on the request form: two long-text boxes, a dropdown, a number, a date and a file. The toggle says whether it is mandatory, and the sequence decides the order they appear in.

42
00:08:36.520 --> 00:08:39.820
Preview Form is the control that proves it.

43
00:08:40.402 --> 00:09:02.588
That is the form somebody filling in a request actually sees. The four fields at the top are structural - the project, the subject, whether it expires and when - and everything below them is built from the rows behind this dialog. Add a property here and it appears there; make one mandatory and nobody can submit without it.

44
00:09:03.188 --> 00:09:15.726
Which is the real answer to "our risk acceptances do not capture X". They can - somebody has to add the field, and then every request from that point on carries it.

45
00:09:16.342 --> 00:09:23.121
You can add property fields, manage them, and preview the resulting form before anyone uses it.

46
00:09:23.734 --> 00:09:39.416
That exists because a risk acceptance is a governance artefact, and governance questions differ by organisation. A regulated bank needs a field a software company does not, and neither should be asking the other's questions.

47
00:09:40.011 --> 00:09:54.807
Use the preview. A form that reads sensibly as a list of field definitions can be thoroughly confusing as something to fill in, and the person filling it in is usually under time pressure and not a security specialist.

48
00:09:55.425 --> 00:10:10.292
One design note worth passing on. Ask for the compensating control and the review date as their own fields rather than trusting a free-text box. Anything you want to report on later has to be a field now.

49
00:10:10.882 --> 00:10:18.812
Once approved, a temporary deviation runs until its end date, and then the second automatic transition happens.

50
00:10:19.419 --> 00:10:29.269
An approved deviation whose end date has passed becomes expired. Again automatically, overnight, without anyone marking it.

51
00:10:29.856 --> 00:10:43.258
The finding underneath is not fixed by that, and it was never hidden. It simply stops being covered by an accepted risk, and returns to being something the service level expects you to act on.

52
00:10:43.858 --> 00:11:01.318
You are warned before it happens. The product notifies when a deviation is about to expire and again when it has, and it repeats that monthly rather than once. So an expiry that surprises somebody is a notification that was not being read.

53
00:11:01.900 --> 00:11:17.362
This screen separates them by where they came from - application security, network vulnerability assessment, penetration testing and compliance postures each on their own tab, because the person who has to act differs by source.

54
00:11:17.994 --> 00:11:35.023
At that point there are three honest options. Remediate it, which is what everyone intended. Renew it, with a fresh justification and a new date. Or accept it permanently, if the position has genuinely settled.

55
00:11:35.623 --> 00:11:49.722
What is not an option is letting it sit expired. An expired deviation is the worst of both worlds: the risk is not accepted and the finding is not fixed, and the record says somebody stopped paying attention.

56
00:11:50.336 --> 00:11:55.435
The other side of that screen is the population currently under acceptance.

57
00:11:56.023 --> 00:12:11.729
It carries the full lineage of each finding - organisation, business unit, project, application and its type - then the audit it came from, that audit's type, its cycle, and when it was created, completed and first reported.

58
00:12:12.323 --> 00:12:19.678
Then the finding itself, its severity, the date it was accepted, and the comments that were given at the time.

59
00:12:20.265 --> 00:12:37.003
Audit First Reported On is the column to read alongside the acceptance date. The gap between them is how long the finding was an ordinary open item before somebody decided to accept it - which is a different conversation from the acceptance itself.

60
00:12:37.636 --> 00:12:49.958
And the acceptance comments are worth spot-checking. They are what your organisation will be read back in a year, and a comment saying "approved as per email" is not a justification.

61
00:12:50.551 --> 00:12:54.907
Two practical things to know about how this module behaves.

62
00:12:55.174 --> 00:13:09.390
A deviation's status is maintained against the state of the finding underneath it, not only by people. If the finding is remediated and closed, the deviation covering it does not need to be tidied up by hand.

63
00:13:09.991 --> 00:13:29.825
And deviations are visible as a population in their own right. The value of that is not administrative - a list of everything your organisation has agreed not to fix, with dates against it, is one of the more useful risk documents you can produce, and most places cannot produce it at all.

64
00:13:30.421 --> 00:13:49.514
That is Deviations and Risk Acceptance. Permanent decisions and temporary ones, and only the temporary ones expire. An approval chain configured per severity, per project and per whether it is a renewal. And two automatic transitions nobody triggers.

65
00:13:50.092 --> 00:14:04.670
Watch two columns and this module runs itself. Pending On tells you who to chase. Auto Reject End Date tells you by when - because a request nobody approved in time does not wait, it dies.

66
00:14:05.255 --> 00:14:19.065
And if you take one habit, take this one: set the end date to when you will genuinely revisit the risk, not to when you hope to have forgotten about it. The product will hold you to that date either way.