Administration: every screen, column and action

User access, audit configuration and the master data other modules read.

Users

Column	What it holds
User Details	Name and contact
Roles	Which roles the account holds
Username	The sign-in name
User/Auditor	Whether the account performs assessments as well as using the platform
IP Group	Which address range they may sign in from
Created By	Who provisioned them
Last Sign-In	When they were last active
Status	Active, inactive or locked

Row actions — six

Action	What it does
Edit User	Account details and roles
Edit User Level	The seniority tier used in approval chains
Edit Asset Ownership	Which assets this person owns
Export Application	The applications they can see
Unlock User	Clears a lockout
Delete User	Removes the account

Edit Asset Ownership from here, not from each asset

When someone joins or leaves, their ownership has to move. Doing it asset by asset is the slow path and the one that leaves orphans; this action reassigns everything they own in one place.

Ownership is also visibility — an owner sees their assets and the findings on them — so leaving a departed user as owner means nobody is receiving those notifications.

Directory-backed accounts

When an account is created as an Active Directory user, the form requires a Directory — which of the configured directories the account authenticates against. It is mandatory because the same username can exist in more than one directory, and the pairing of the two is what identifies the person.

Choosing the wrong directory produces an account that looks correct in the list and fails at sign-in with an invalid-credentials message. Correcting it is an edit, not a re-create.

User/Auditor matters because auditors appear in assignment lists across every assessment module. An account not flagged as an auditor cannot be assigned to an audit, which is a common "why can't I select this person" question.

Last Sign-In is the column for an access review. Accounts with no sign-in for months are the ones to question first.

Page-level actions

Export Users, Download all users with assets, Upload CSV, View Bulk Update Logs.

Download all users with assets is the access-review export: every user with everything they can reach, which is what an auditor asks for and what nothing else in the product produces.

The bulk update queue reports Status, Summary, Initiated By, Initiated At and a Download Log File — the per-row outcome of a CSV upload.

Roles, groups and levels

Screen	Columns
Roles	Roles, Created By, and the members — User Id, User Name
User Groups	User Group Name, Organisation, No of Users, Created By
User Levels	User ID, Level 1, Level 2, Level 3, Created By
Super Admins	User ID, User Name, Created By

User Levels are three independent tiers, not one ladder. They are used by approval chains to decide who can approve what, and a user can hold a different level in each — which is how an organisation models someone senior in one domain and junior in another.

Super Admins deserve a periodic review of their own. The list is short by design, and anything on it has unrestricted access.

IP restriction

Screen	Columns
IP Groups	IP Group #, IP Group Name, Additional Info, Created By
Assigned IPs	IP Address ID, IP Address, Remarks, Created By

Actions: Assign IP, View Assigned IPs.

Sign-in can be restricted to an address range per user. Remarks is where the justification goes — "site VPN egress", "vendor jump host" — and an entry without one is impossible to review later, because an IP address alone tells you nothing about why it was permitted.

Audit configuration

Screen	Columns
Audit Types	Audit ID, Audit Type, Created By, Status
Audit Properties	Property Name, Property Type, Created By
Property management	Asset Type, Audit Type, Properties
Manage properties (dialog)	Property Name, Property Type, Sequence, Mandatory

Properties are mapped per asset type and audit type together, so a property meaningful for a web DAST audit need not appear on a network VA. Mandatory blocks audit creation until filled — the usual reason an audit that used to save now will not.

Master status tables

The RLCM masters are administered here rather than in the module:

Screen	Columns
Audit status	Audit Status, Colour, Audit Status Order, Comment Required, Auditor Required, Closed Type
Risk status	Audit Finding, Colour, Audit Status Order, Comment Required, Evidence Required, Closed Type, Is Exception
Priority status	Priority Levels, Colour, Priority Order

Four flags decide behaviour, and all four are enforced at save time rather than announced in advance:

• Comment Required — will not save without one
• Auditor Required — needs an auditor assigned before the status can be set
• Evidence Required — needs an attachment
• Closed Type — whether the status stops something counting as open

Is Exception marks a status representing an agreed exception rather than a resolution. It is what separates "we fixed it" from "we agreed not to", and reporting that conflates the two overstates remediation.

Advisories

CVE, Regulatory Name, Date, Status, Created By.

Actions: Upload Advisories, Export Advisories, Manage Regulatory Master.

Advisories publish a coordinated response inside the platform. Regulatory Name links one to the regulator that issued it, which is what makes an advisory a compliance obligation rather than an internal notice — and the reason the regulatory master is maintained separately.

Network VA grouping

Groups — Group Name, Sub Groups. Sub-groups — Sub Groups Name, Group Name.

Two levels of grouping for network assets, usually site then environment. Findings inherit the grouping of their host, so this is what makes "which site is worst" answerable.

Test cases and plans

Screen	Columns
Categories	Category No., Category Name, Report Type, Created By
Test cases	The cases within a category

Actions: Manage Test Cases, Edit Test Case, Delete.

A test plan is a set of cases grouped into categories, worked through during a manual assessment. Report Type ties a category to the report it appears in, so what the tester records and what the customer receives stay aligned.

Without a plan, a manual audit's scope exists only in the tester's memory — which is the difference between an assessment an auditor accepts and one they do not.

Test plans carry Test Plan ID, Test Plan Title, Report Type, Created By, with View Status History showing how a plan has changed — which matters when two assessments run against the same plan produce different coverage.

Email templates

There are two screens here, and they do different jobs.

Scheduled email reports are the recurring security reports you build yourself. Each definition carries Name, Data Type, Dispatch, Trigger, Status, Updated.

• Dispatch is how many emails go out — Shared is one to a fixed audience, Group By is one per owner, each carrying only that owner's findings.
• Trigger is the send cadence, not an event: Daily at 06:45, Weekly, day 4 at 08:30, Monthly, day 1 at 08:00.
• Status must be Active to be scheduled at all. A finished definition left on Draft is the usual explanation for a report nobody receives — followed by test mode still being on, which the list flags beside the name.

Building one is covered in full in Design a scheduled email report — data sources, body blocks, attachment, recipient resolvers, branding and the safe way to go live.

Notification templates are the platform's own transactional mail — the wording sent when an audit completes or a password reset is requested. That list shows Scenario, Triggered On, Triggered At, Frequency, Send and Status:

• Scenario — the situation the mail covers, such as an SLA approaching expiry
• Triggered On — the event that fires it
• Triggered At — the time of day it goes, for scheduled mail
• Frequency — how often, for anything recurring
• Send — sends a scheduled template now, off-schedule, to the recipients it would resolve to at the next scheduled send. It does not move the schedule: the next scheduled send still happens when it was due

Frequency is why a notification arrives late rather than not at all

A template with a daily frequency and a fixed time sends once a day, not when the event occurs. A user reporting that an SLA warning "came a day late" has usually met exactly this — the event happened after that day's send.

Email logs

Email Type and ID, Subject, To, CC, Added On, Triggered By, Status.

Triggered By distinguishes a mail the schedule sent from one a person sent with Send — which is the first thing to check when a recipient reports receiving a report twice on one day.

The record of what was actually sent. Status distinguishes queued from sent from failed, and To / CC show who received it — which settles "I was never told" without involving the mail administrator.

Added On is when the mail was queued, not when it was delivered. A large gap between Added On and an absent delivery points at the mail server rather than at NxSAM.