WEBVTT

1
00:00:00.622 --> 00:00:12.534
Welcome to NxSAM training. This module covers Asset Management: the structure underneath the asset inventory, and how assets get into the platform and stay current.

2
00:00:13.134 --> 00:00:28.575
The Assets module covers the inventories you work in daily. This one covers what makes them mean anything - the grouping every report uses, the properties every filter offers, and the synchronisation that keeps it all true.

3
00:00:29.186 --> 00:00:34.454
Start with the grouping, because everything downstream reports against it.

4
00:00:35.051 --> 00:00:47.567
Three levels. Organisation at the top, business units in the middle, and projects at the bottom - and every asset sits under a project, which sits under a business unit.

5
00:00:48.165 --> 00:00:53.194
Business units are the level most executive reporting groups by.

6
00:00:53.780 --> 00:01:01.038
And projects are the level most operational reporting groups by, which makes them the one worth keeping tidy.

7
00:01:01.609 --> 00:01:19.667
A project created casually for one audit does not stay in that audit. It appears in every report that groups by project, for as long as the assets under it exist. Naming these deliberately costs a minute and saves years of untidy reporting.

8
00:01:20.246 --> 00:01:26.114
Then the extension point, and this is the part of the module worth understanding properly.

9
00:01:26.716 --> 00:01:42.375
The list gives each a property name, a property type, and who created it. Property type is the decision everything else depends on: a chosen value can be filtered, grouped and reported on - free text can only be read.

10
00:01:42.975 --> 00:01:59.212
An asset property is a custom field your organisation defines on assets. Business criticality, data classification, regulatory scope, environment, business owner - whatever you need to record that we did not think of.

11
00:01:59.829 --> 00:02:11.097
Defining one is not just adding a field to a form. This is the part people underestimate, so it is worth being specific about where a new property turns up.

12
00:02:11.694 --> 00:02:30.979
It becomes a filter on the analytics dashboard. It becomes a grouping option in the custom chart builder. It becomes something you can group scheduled emails by, so one template can produce one email per owning team. And it becomes available on exports.

13
00:02:31.587 --> 00:02:48.206
Which means a property is the single highest-leverage thing you can configure in this platform. Record who owns an asset, and suddenly you can report by owner, chart by owner, and email by owner - none of which required any development.

14
00:02:48.814 --> 00:02:54.316
Property management is where values are administered once a property exists.

15
00:02:54.904 --> 00:03:12.795
One piece of advice from watching people set these up. Prefer a small number of properties that are always filled in over a large number that are usually blank. A property that is populated on thirty percent of assets produces reports nobody trusts.

16
00:03:13.388 --> 00:03:18.580
The asset owner master holds the people who can be assigned as owners.

17
00:03:19.171 --> 00:03:32.096
Ownership drives two things at once, which is why it matters more than it looks. It decides who is chased when findings age. And it decides who can see the asset at all.

18
00:03:32.683 --> 00:03:44.431
So if a colleague cannot see an asset that you can, that is ownership working as designed rather than a fault - and the fix is an ownership or role change, not a data repair.

19
00:03:45.022 --> 00:03:52.519
The network asset map relates hosts to the applications running on them, and it earns its place in two directions.

20
00:03:53.111 --> 00:04:10.170
Forwards: a finding on an application can be traced to the infrastructure underneath it. Backwards: a host about to be patched can be traced to everything that patch will affect. That second direction is the one that prevents outages.

21
00:04:10.796 --> 00:04:16.662
Assets reach the platform three ways, and the third one changes how you should work.

22
00:04:17.255 --> 00:04:31.932
Created directly, one at a time, from the inventory screens. Uploaded in bulk from a spreadsheet, which is what Upload Assets on this screen does. Or synchronised from a source of truth.

23
00:04:32.556 --> 00:04:44.735
Bulk upload is the right tool for an initial load or a large addition. It is the wrong tool for routine maintenance, because a spreadsheet is a snapshot and your estate is not.

24
00:04:45.351 --> 00:04:52.033
Which brings us to synchronisation, and the one rule everybody who touches the inventory needs to know.

25
00:04:52.600 --> 00:05:01.951
Sync configuration maps a source system's columns onto the platform's asset fields, and sets the schedule the synchronisation runs on.

26
00:05:02.544 --> 00:05:13.330
And here is the rule. Where a synchronisation is configured, the source system is authoritative. Make changes there, not here.

27
00:05:13.927 --> 00:05:31.072
Because a local edit will simply be overwritten on the next run. Not rejected, not flagged - overwritten. Somebody corrects an owner in the platform, the sync runs overnight, and the correction is gone with nothing to show it ever happened.

28
00:05:31.649 --> 00:05:44.739
The mapping deserves the same care. If the source identifies a host differently from how the platform does, you get two assets where you meant one, and the findings divide between them.

29
00:05:45.337 --> 00:05:49.626
Finally, what happens when an asset stops existing.

30
00:05:50.211 --> 00:06:04.359
Assets that no longer exist should be decommissioned rather than deleted. Decommissioning removes the asset from active tracking while preserving its history, so past findings and past reports stay intelligible.

31
00:06:04.944 --> 00:06:20.529
This screen holds those requests: a decommission identifier, the initiator, the status, and who it is pending on. Retiring an asset is an approval rather than a switch - somebody has to confirm it really is gone.

32
00:06:21.153 --> 00:06:34.956
Pending On does the same job here as it does in risk acceptance: it names the person a request is sitting with. A decommission that has not moved is something to chase rather than something to investigate.

33
00:06:35.525 --> 00:06:51.733
And it is worth working that list, because an asset awaiting decommission is still in every count. Until the request is approved it continues to carry findings, age against its service levels, and appear in the totals somebody reports on.

34
00:06:52.322 --> 00:06:56.892
One more screen, which sits slightly apart from the rest.

35
00:06:57.511 --> 00:07:06.905
The audit calendar planner plans assessment coverage across a period. Each plan shows how much of it has actually been done.

36
00:07:07.487 --> 00:07:23.435
That second half is the point. A plan that records intention is a document. A plan that shows execution against intention is a control - it makes a plan nobody is executing visible, rather than merely filed.

37
00:07:24.006 --> 00:07:44.222
That is Asset Management. A three-level hierarchy everything reports against, properties that become filters and groupings across the whole platform, ownership that decides both responsibility and visibility, synchronisation where the source is authoritative, and decommissioning that preserves history.

38
00:07:44.513 --> 00:08:00.437
Two things to carry away. Define the properties you will actually populate, because they unlock reporting everywhere. And if a sync is configured, change the source system - anything you fix here will quietly disappear.