Security Processes

Write down the security work your organisation actually performs — patching, vulnerability management, EDR, backups — and evidence that it runs by linking the tickets behind it.

A security process is a security activity you perform again and again: applying patches, chasing vulnerabilities, running endpoint detection, watching a SIEM (a system that collects and correlates security logs), restoring from backup. This module gives each one a named home — an owner, the tooling that powers it, a review cadence, an objective — and attaches the external tickets that show the work happening. When an auditor asks "how do you patch?", you open the process, read the objective, and show the tickets underneath it.

Aegis does not perform the work. You define the process and record the ticket references; the page counts how many are linked and how many are still open, so the picture stays honest.

Who uses it

Reading is open to every role; editing sits with Contributor, and creating or deleting with Manager and above.

What's on this screen

Open Security Processes from the Governance group in the left sidebar. The page leads with its title and a one-line subtitle: define the active security processes and track their execution through linked tickets. Managers and Admins also see a New security process button at the right of that header row; the screenshot below was captured as Contributor, which is why no such button appears.

Under the header sits a three-part filter bar — a search box, an All types dropdown and an All statuses dropdown. Processes appear below as cards in a grid, and the foot of the page carries Page 1 of 1 with Previous and Next buttons, greyed out while there is one page.

1. Type into Search security processes... to narrow the grid by name. The list refreshes shortly after you stop typing and pagination returns to page one.
2. Open All types to show one kind of process only — Patch management, Vulnerability management, SIEM monitoring and so on. The grid redraws at once.
3. Open All statuses to show only Active or only Inactive processes. The three filters combine.
4. Read a card's body for the working detail: Owner and Tooling on the middle lines, then two counts at the foot — linked tickets and open tickets. The tooling line is left out when nothing is recorded.
5. Select the card to open the process. Aegis navigates to the detail page, where the tickets and the AI actions live.

The captured example holds one process, patch process, badged Patch management and Active, with tooling Intune and counts of 1 linked ticket and 1 open ticket — a defined capability with one piece of evidence, still outstanding.

Define a new security process

Select New security process. A modal titled Define security process opens over the page.

1. Enter the Name — what your organisation calls this work, such as Monthly OS patching. Required, up to 200 characters.
2. Pick a Type from the fixed list: Patch management, Vulnerability management, EDR, NDR, SIEM monitoring, Incident response, Backup & recovery, Access management, Change management, Other. Required; it drives the coloured badge on the card.
3. Choose an Owner. This picker appears only if your role may list users; otherwise the process is created without one and a Manager sets it later.
4. Fill in the optional fields: Tooling (free text, up to 500 characters — for example CrowdStrike Falcon) and Review cadence (free text, up to 200 — for example Quarterly), then the Objective — what the process must achieve and how success is measured — and a Description of its scope, each up to 5,000 characters.
5. Select Create. The modal closes, a Security process created confirmation appears and the card joins the grid. New processes always start Active — there is no status field on the create form.

Open a process and read its detail

Selecting a card opens /security-processes/<id>, with a ← Back to security processes link at the top-left. The header repeats the name and its two badges, shows the description, then a line of facts: Owner, Review cadence (only when recorded) and the live open ticket count. On the right sit Review Gaps & Controls, Validate & Optimize, Edit and Delete — the last two only for roles that hold them. Below come the Objective and Tooling panels, shown only when filled in, then Tickets, External ticket sources, and the saved AI insight history.

Link a ticket as evidence

Linking tickets turns a definition into evidence, and it is a Contributor task. A row here is a reference to a ticket in your own tracker; the ticket itself stays where it is.

1. In the Tickets section, select Link ticket. A modal opens.
2. Enter the Ticket reference — its identifier in its home system, for example OPS-431. This is the only required field.
3. Add a Title and a URL if you have them. A valid web address turns the reference into a clickable link in the table; unsafe addresses are stored but never linked.
4. Set the System the ticket lives in and its starting Status, and use Notes for context a later reader will need.
5. Select Link. The ticket appears as the newest row, a Ticket linked confirmation shows, and both counts — on the process and on its card in the overview — update.

The table has columns Reference, Title, System, Status, Linked by, Closed and Actions, its own All statuses and All systems filters, and pagination below. For roles that may edit, Status is an inline dropdown: change it in the row and it saves at once; read-only roles see the status as a badge instead. Moving a ticket to Closed stamps the Closed date, and moving it back clears the date — you never type it. Edit reopens the full form; Delete is offered to Manager and above behind a confirmation.

Connect an external ticket source

Under the tickets table sits External ticket sources. It binds a connector you have already configured — Jira, GitHub, SharePoint or ServiceNow — to one list or project, so tickets from that list are pulled into the table above. It needs connector-management rights, so it is a Manager or Admin task.

1. Select Connect source. The Connect ticket source modal opens; with no eligible connector configured it says so and points you at the Connectors page — credentials are never entered here.
2. Choose the Connector from the dropdown of what is already set up.
3. Enter the List / project reference — a Jira project key, a repository, a SharePoint list or a ServiceNow queue. Required.
4. Add an optional Filter (a JQL query, a label, a milestone) to narrow what is followed, and leave Ingestion enabled unless you want the binding recorded but dormant.
5. Select Connect. The source joins a table of Connector, List / project, Filter and Enabled, with Edit and Remove beside it. Removing it detaches the source and leaves the connector untouched.

Once a source is connected and left enabled, a background job walks it on a schedule — every 15 minutes unless your operator has changed that — and creates or updates a row in the Tickets table for each ticket it finds, filling the reference, title, URL, system, status and closed date from the source. Rows are matched by reference and system, so a ticket you had already linked by hand is adopted rather than duplicated. There is no Sync now button here: a binding you disable, or one whose connector is not connected, is skipped.

The AI assist

Two AI actions sit in the detail header. Both read your own records only, both stream their working as they go, and both produce advice for a person to weigh — neither changes anything on its own.

• Review Gaps & Controls compares the objective against the tooling, the cadence and the evidence. It reports coverage gaps, proposes the framework controls (NIS2, ISO 27001, CyFun, DORA) this process should map to, checks whether cadence and evidence are still fresh, and drafts a tighter description you may adopt or ignore.
• Validate & Optimize works on the linked tickets. It names mismatched, dangling, stale or duplicate links by reference; summarises KPIs — open against closed volume, mean time to close, on-time-close rate, overdue backlog, throughput, evidence freshness; and proposes a prioritised improvement plan. The KPIs and the main findings are calculated from your ticket rows; the AI ranks and narrates them.

Either button opens a modal that first sets out what the run covers; nothing is sent until you select Run review or Run validation. In the Validate & Optimize result, each proposed improvement carries a Create action item button, which creates a tracked item linked back to this process for follow-up under Action Items. Either result can be kept as a record; saved runs appear in the insight history panel at the foot of the page, so a later reader sees what was advised and when.

Edit, retire or delete a process

Edit reopens the same form you created with, now titled Edit security process and carrying one extra field, Status. Everything stays editable, including the type — a mis-classified process can be re-typed at any time. To retire a capability you no longer operate, set Status to Inactive: the process, its tickets and its sources all remain, and the card is badged Inactive in the overview. Delete is a Manager-and-above action behind a confirmation warning that the ticket links will no longer be visible.

The empty state

Before any processes exist, the grid is replaced by a panel headed No security processes yet, with a New security process button inside it for roles that may create. The filter bar stays visible in every state, which matters for the other empty case: when a search or filter matches nothing you see No security processes match the current filters. — clear the search box and return both dropdowns to All types and All statuses.

Tips and limits

• The counts are Aegis's counts: they reflect the ticket rows recorded here. A ticket you linked by hand does not follow its tracker — close it in Jira and it stays Open in Aegis until someone changes it. Only rows brought in by an enabled source are refreshed for you, and then only as often as the job runs.
• Tooling and cadence are free text with no controlled vocabulary. Agree a house style — "Quarterly" and "Every 3 months" will not group together.
• Ticket references are not validated — Aegis accepts one that points nowhere. The Validate & Optimize run is the check that flags dangling and stale links.
• An owner is optional but worth setting: a card reading Owner: No owner is a process nobody has been asked to run.
• A ticket link is a pointer to evidence, not the evidence itself. For documents and artefacts an auditor will read, use Evidence.

Where this connects

Security Processes sits in the Governance group beside Security Standards, Governance Bodies and Security Awareness. The controls these processes support live under Compliance Frameworks and Control Monitoring. Ticket sources reuse the integrations in Connectors; AI-raised improvements land in Action Items. For the limits of your role, see Roles Overview.