Access Governance Requirements

This program exists because access lives in two very different worlds at once. Entra ID, Google Workspace, GitHub, Mimecast, Akamai, and Proofpoint are cloud-managed and mostly SSO-federated — they can be discovered and governed automatically. Active Directory, on-prem firewalls, Portainer, Syspass, and vendor support portals are local-only — nobody's API tells you who has access; a human has to know, tag it, and check back. A workable program has to treat both as first-class, not bolt the second one on as an afterthought.

01 Environment inventory & risk register

Every system in scope, tagged by how it's reached today and what risk attribute needs tracking against it. This table is the seed for the "Data Sources" and "Unmatched accounts" views already prototyped — it's the thing that actually needs populating first, before any tool is bought.

"Manual tag" means: no vendor API will hand you this list — a person enters and periodically reconfirms it. That's a process requirement, not a tooling gap a product purchase fixes on its own.

02 Requirements

Functional

Non-functional

• Scale: 100–300 named human users, plus an unbounded number of non-human identities — API keys and service accounts commonly outnumber humans 2–3×, so pricing and data-model decisions can't assume one identity per person.
• No secrets stored here: this system references vault entries (Syspass, or its successor) by ID/label only. It never stores or displays a plaintext credential — that stays in the vault, which stays the single place rotation actually happens.
• Data residency: whatever holds the sync/store layer should be deployable in a region or tenant the organization controls — consistent with why AD, Portainer, and the firewalls are self-hosted in the first place.
• Role-based access to the tool itself: most staff see only their own access map; security/IT admins see the org-wide view and the orphaned-account register.
• Audit retention: history kept for at least the recertification cycle (12+ months rolling) to serve as compliance evidence without a separate export process.

Integration & review cadence

• Jira — system of record for every access grant, revoke, recertification, and offboarding checklist; ticket status read back to close the loop, matching the prototype's per-access-grant ticket model.
• Slack — due-date reminders (recert, password rotation, refresh completed), DMs to individual asset owners, and a channel feed for the security team on newly-flagged orphaned accounts.
• Others — email fallback for anything with no chat presence (vendor support-portal-only logins), Microsoft Teams if used alongside Slack, and a generic webhook for anything not yet on the list.
• Recertification cadence — quarterly by default; configurable per risk tier (e.g. 90 days for AD/firewall privileged accounts, 180 days for low-risk SaaS seats).
• Password rotation cadence — separate schedule for shared/local accounts (e.g. 90 days for Syspass-held admin credentials), escalating via Slack then Jira if the due date passes unactioned.

03 Recommended architecture

Two different discovery mechanisms feed one register, because they have to: federated systems can be polled, local-only systems can only be told. Everything downstream — recertification, rotation reminders, offboarding, ticketing — runs off that one register so a reviewer never has to know which half of the org a given account came from.

The box worth being honest about is the "Workflow engine" — it is not a product you buy, it's the piece that has to be built or configured (Jira/Slack automation rules, or a small custom service) to actually connect the register's state to a ticket and a notification. Everything to its left has a commercial product that can fill it in; this piece is glue.

04 Cost model — 100 to 300 users

Grounded in currently published pricing where available; vendor-quoted tools are marked as estimates. None of this includes the internal engineering time for the workflow engine and on-prem register.

SaaS discovery & governance layer

Shared/local credential vault (Syspass successor or complement)

Ticketing & chat

Jira and Slack are assumed already licensed. Incremental cost is integration/automation effort (webhooks, Jira automation rules, Slack app), not new per-seat licensing.

Indicative total — realistic hybrid stack

Ranges are directional, built from currently published rate cards and market-comparison commentary — confirm every "estimate" line with a written vendor quote before budgeting against it.

05 Phased rollout

06 Vendor evaluation checklist

Questions worth asking any SMP/IGA vendor before signing, specific to this environment's gaps:

1. Can it hold a manually-tagged record for a system it has no API for (Portainer, local firewalls), alongside the auto-discovered ones — in the same data model, not a bolt-on spreadsheet?
2. Does it expose a vendor-AI-data-processing risk field per connected app, or would that have to be tracked separately?
3. Is Jira/Slack integration native, or does it require a middleware/webhook layer you'd build and maintain?
4. Is pricing per human user, per total account (including service accounts/API keys), or per connected app — this changes the real cost materially once non-human identities are counted?
5. Does quarterly recertification support a different cadence per system/risk tier, or is it one global schedule?
6. What happens on offboarding for a system with no revoke API — does it generate a checklist, or silently do nothing?
7. Get the 100-user and 300-user price in writing — the estimates in Section 4 are directional, not quotes.

07 Inventory methodology & schema

Automation keeps an inventory accurate; it does not build one. The first pass has to be a thorough manual pull, done once, before any scheduled sync starts maintaining it.

1. Pull the real account list, not the assumed one. For every system in Section 1's register, export the actual account list from its admin console — every login it has, not "who we think has access."
2. Join every human account against the HR roster. Any active account with no matching active employee is an orphan candidate on day one — this single join finds more orphans than any tool will, and it's a spreadsheet operation, not a purchase.
3. Classify every remaining account using the schema below, including the non-human ones (service accounts, API keys) — these never join against HR, so they need their own orphan test (Section 9).
4. Only then turn on scheduled read-only pulls — their job is to diff against this now-trustworthy baseline and surface changes, not to perform discovery from a cold start.

Inventory schema

One row per account (not per person, not per system) — a user with five platform logins is five rows. Ready to use as a spreadsheet or as the on-prem register's data model.

08 SSO / local-account consolidation

The single highest-leverage structural move available: every account moved onto SSO stops needing manual tagging and inherits whatever already governs Entra/AD — conditional access, MFA, automatic recertification. Do this per platform, not per account, and close the local account once its SSO replacement is confirmed working. Leaving both live "just in case" is exactly how orphans get created.

09 Orphan & service-identity prevention

Detection (Section 1's HR join, Section 7's scheduled diff) only ever finds an orphan after it exists. Prevention means closing the creation path so an unowned account can't quietly appear in the first place.

Creation-time control

No service account, API key, or new local account gets created outside one path: a Jira request template that forces an owner, a business justification, and a review date before the account is created. Anything discovered later that has no matching ticket is, by definition, an audit finding — this is what "Linked ticket" in the schema enforces.

Detecting existing orphans, by account type

Read-only pull cadence, by source type

Every pull's job is to surface a diff for a human to act on — new account, removed account, changed role — never to silently reconcile itself.

10 Review & rotation cadence

Quarterly is a reasonable, defensible cadence specifically because VPN-gating and local-only exposure lower the account's attack surface relative to anything internet-facing — but the review answers "does this still need to exist," not "was it misused since the last check." That second question needs continuous monitoring regardless of review cadence; don't let the quarterly cycle stand in for it.

11 Vendor fit comparison

Run this same table against any candidate's live demo before shortlisting — no vendor is named as a recommendation here deliberately, since the right column split depends on which slice of your environment (Section 1) each product actually reaches.

Both columns leave the same two gaps: FR-2 (on-prem register) and FR-5 (credential rotation). No vendor in this category closes either — that part of the architecture (Section 3) stays a build regardless of which vendor wins the SaaS-discovery slice.

12 Integration design principles

The integrations themselves need the same governance discipline as the accounts they're tracking — a read pull that's over-scoped, or a ticket that silently never closes, undermines the whole program.

Least privilege for the tool's own credentials

The workflow engine and register are themselves a new set of service accounts/API keys — subject to every requirement in Sections 7–9, starting with minimal scope.

Jira ticket lifecycle (open and close)

A ticket that only ever gets created and never verifiably closed is worse than no ticket — it looks like governance while providing none. Every ticket this program opens follows one of two paths to closure:

The manual-completion-notes field is a required custom field on this ticket type, not a comment left to discipline — a ticket can't transition to Closed without it. This is what makes "manual settings" auditable instead of just trusted.

API key / service-account Slack alerts

These run on their own trigger set, separate from the human recertification reminders in Section 10 — a non-human identity has no one checking a personal inbox for it.

13 Open-source tooling map

Every box in the Section 3 architecture diagram has a genuine, actively-maintained open-source candidate — this isn't a cost-cutting fallback, one of these (Teleport/JumpServer) is structurally better than the vault-and-rotate pattern for local access, not just cheaper.

Commercial tools still lead on prebuilt connectors, AI-driven access insights, and continuous SaaS/shadow-IT discovery specifically — the gap named in Section 11 doesn't close with open source either. What changes here is everything downstream of discovery: governance, on-prem access brokering, and the workflow glue all have credible, free, self-hosted answers.

14 Demo-to-requirements traceability

The interactive prototype is a UI/interaction proof, not the production system Sections 1–13 spec out — it mocks every data source client-side and persists nothing server-side. This table is an honest accounting of which requirements it actually demonstrates, versus which are out of a front-end mock's reach by design.

"Demonstrated" means the interaction and its data model work end-to-end in the browser session — not that it's wired to a real Entra/Jira/Slack API. Nothing in the prototype persists past a page reload; that's the one gap every row above shares, and it's the entire reason Sections 1–13 exist.

15 Security requirements — OWASP, NIST, NZISM

Every control below is scoped to this tool's actual attack surface: it pulls read-only identity/asset data from Entra ID, Google Workspace, and Workday; writes narrowly to one Jira project; sends alerts to Slack; carries its own RBAC layer (Section 2's NFR); and — precisely because it becomes a single index of every access grant in the org — is itself a high-value target. Generic checklist items not tied to one of those five surfaces are deliberately left out.

OWASP Top 10 (2021) mapping

NIST CSF 2.0 alignment

Relevant NIST SP 800-53 control families (not specific control numbers, which aren't verified here): AC (Access Control) for RBAC and connector scoping; IA (Identification & Authentication) for tool login/MFA and service-account auth; AU (Audit & Accountability) for the A09 logging above; CM (Configuration Management) for connector config and dependency management; SI (System & Information Integrity) for the A08 data-integrity concerns. Pull exact control numbers from the current SP 800-53 Rev. 5 catalog before citing one formally.

NZISM-aligned access-control principles

• Least privilege — every RBAC role and every connector scope is the minimum needed for its function (concrete controls under A01/A05/Protect above).
• Separation of duties — the person who can approve a Jira-write action from the tool is not the same person who can edit the underlying register directly; recertification approval and record modification are distinct permissions.
• Need-to-know — org-wide register visibility is restricted to security/compliance leads; department-scoped views (Section 2's NFR) are the default for line managers.
• Session & credential management — short session timeouts and MFA for human users (A07); the tool applies its own rotation-tracking feature (FR-5) to its own connector credentials, not only to the accounts it's tracking for the org.

Data, access & management — consolidated requirements

• Data classification: the register is sensitive/restricted — it's a map of who can access what across the org — distinct from lower-sensitivity metadata like vendor names or asset models.
• Encryption at rest and in transit: TLS for all connector traffic and the tool's own UI/API; encryption at rest for the primary datastore and any exported/cached directory data.
• Retention and deletion: a defined retention period for audit/history (interacting with Section 10's cadence) and a defined deletion process for departed-employee records, distinct from just marking them offboarded in the UI.
• Backup and disaster recovery: back up the register and its audit trail; recovery priority is history integrity/availability, not "restoring access," since the tool sits outside the authorization path.
• Data residency: confirm where the datastore and any SaaS backend are hosted — consistent with the NFR in Section 2 and the NZISM framing above.
• Access logging and audit-trail immutability: logs of who viewed/exported the register and who took Jira-write actions are append-only/tamper-evident — this log is close to the tool's core evidentiary value to an auditor.
• Admin access to the tool itself: a small, named admin set with documented break-glass procedures; admin actions on the tool are themselves logged.
• Secrets management: Entra/Google/Workday/Jira/Slack credentials live in a proper secrets manager, never in env files or source control, with rotation tracked the same way the product tracks rotation for the accounts it governs.

Purpose and scope — if this were built out for real

This tool would exist to give IT, security, and compliance teams a single source of truth for who has access to what across hardware, licenses, and platforms — and, critically, to tie every grant back to the Jira ticket that authorized it, closing the common gap where access is granted informally and never traced or revoked. It's built for the people who have to answer "why does this person still have access" during an audit or offboarding review — IT admins doing day-to-day provisioning, security/compliance leads running periodic recertification, and external auditors needing evidence — not for end users managing their own accounts. It is explicitly not an IAM/SSO replacement (it reads from Entra/Google/Workday; it authenticates no one), not a PAM/credential vault (it tracks that a credential exists and needs rotation; it never brokers or stores the credential itself), and not a substitute for the SaaS Management Platforms or Entra ID Governance discussed in Section 11 — it's a narrow governance and traceability layer that sits on top of those systems, valuable precisely because it doesn't try to re-implement what they already do.

16 Connecting real data sources

Could this run against a real organization's data today? Not as-is — the prototype's USERS/SOURCES are in-memory JavaScript arrays with no backend, no auth, and nothing persisted. What is reusable is the interaction design and data model (Sections 7, 9, 14) — the graph, the audit table, the drawer, the ticket lifecycle all assume the same shape of record regardless of where it came from. Making it real means building one thing per source system: a connector that reads that source and normalizes it into that shape, plus the backend, storage, and auth layer the demo has none of (Section 17).

One contract, every source type

Every connector — whether it talks to a REST API, a SQL database, or LDAP — implements the same four rules, so the register upstream of it never needs to know or care which kind of source it's looking at:

• Read-only credential, always. No connector holds write access to the system it's reading from, full stop — even where the underlying platform would technically allow it (Section 12, Section 15 A05).
• Incremental, not a full re-pull. Every fetch is scoped by a watermark (a timestamp or version column) so a sync touches only what changed since the last run — this is what makes daily/weekly cadences (Section 9) cheap enough to actually run on schedule.
• Emits a diff, not an overwrite. A connector's output is "these 3 accounts appeared, these 2 changed role, this 1 disappeared" — never a silent full replace of the register, which is what makes Section 9's diff-review model possible at all.
• Normalizes to Section 7's schema on the way in. Whatever the source calls its columns, the connector's job is mapping them to Account ID / Account holder / Account type / Linked ticket / etc. before anything downstream sees the record.

By source type

Deep dive: connecting a Postgres / SQL data source

This is the source type most likely to be a real internal system (an HR database, a homegrown app-role table) rather than a vendor API — so it gets the most direct scrutiny, since nothing about it is off-the-shelf.

• Prefer a read replica over the primary. A sync job's queries should never compete with production OLTP traffic — if no replica exists, that's a prerequisite to build, not a reason to point the connector at primary.
• Create a dedicated role — never reuse an existing app's credentials:

  CREATE ROLE access_register_reader LOGIN PASSWORD '…' NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT; GRANT SELECT ON v_employee_directory, v_app_role_assignments TO access_register_reader; ALTER ROLE access_register_reader SET default_transaction_read_only = on;

• Expose data through views, never base tables. A view reshapes and redacts columns before the connector ever sees them — e.g. excluding a salary or national-ID column that happens to sit in the same physical employees table — and lets a DBA change the underlying schema without breaking the connector's contract.
• Filter every pull by a watermark: SELECT * FROM v_app_role_assignments WHERE updated_at > $last_watermark, never an unfiltered table scan on a recurring job.
• Lock down the connection itself: TLS-only (sslmode=verify-full), reachable only from the connector's own network segment (VPC peering/PrivateLink or a bastion — never a public endpoint), with a strict statement_timeout so one bad query can't hang or load-spike the source database.
• Rotate the role's credential on the same cadence the tool already tracks for other service accounts (FR-5) — ideally a short-lived IAM-auth token (AWS RDS IAM auth, Azure AD-based Postgres auth) rather than a long-lived static password, stored in the secrets manager from Section 15, never in connector config.
• Enforce read-only twice: once at the grant level (no INSERT/UPDATE/DELETE privileges exist to misuse) and once at the session level (default_transaction_read_only, above) — belt and suspenders, not redundant.
• On replica lag or connection failure, skip and alert — never fall back to accepting a stale or partial read as ground truth for who has access to what.

Schema mapping — example

A connector's real job, reduced to one table: turning whatever the source calls things into Section 7's inventory schema.

Threat model: the data collection points, reviewed

The connectors above are where this program actually touches the outside world — every other component (the frontend, the app layer's own database) is fully within this tool's own perimeter. That makes each collection point worth reviewing individually, as an attacker would: not "is a control listed for this," but "what happens if this specific point is compromised, and does the listed control actually hold." The same unresolved-challenge convention from Section 18 applies here — where a gap is real and not fully closed by anything already designed, it's marked as such rather than talked around.

17 Build plan: prototype to production

Section 5 already lays out the rollout on a calendar; this is the technical build order underneath it — the components that have to exist, roughly in the sequence they have to exist in, before Phase 1 of that rollout can point at anything real.

1. Secrets management, before writing a single connector. Stand up Vault/AWS Secrets Manager/Azure Key Vault first — no connector credential is ever hardcoded, even in a dev environment, because "just for now" credentials are exactly how orphaned access starts (Section 9).
2. Connector framework. One interface — fetch since a watermark, return normalized records, emit a diff — implemented per Section 16's contract. Start with the two highest-value sources (the HR system of record and the primary IdP) before adding the long tail of on-prem/local systems.
3. Unified data store. Section 7's schema as real tables, not the demo's in-memory arrays — every write attributable to a specific sync run or ticket action (Section 15 A08), never a hand edit with no trail.
4. Sync orchestrator. A scheduler (n8n, per Section 13, or a cron-based job runner) running each connector on its own cadence from Section 9's pull-cadence table, surfacing each run's diff for review rather than auto-applying every change silently.
5. Backend API + server-side RBAC. The layer the current prototype doesn't have at all: real user authentication, and every permission check enforced in the API (Section 15 A01) — not hidden in the UI the way the demo's Admin/Auditor toggle currently is.
6. Ticketing & alerting integration. Wire real Jira ticket creation/transition and real Slack alerts to real events — a diff detected, a recertification due, a rotation overdue — using the least-privilege scopes already specified in Section 12.
7. Frontend. The existing prototype's graph, audit table, and drawer are largely reusable as-is — swap the hardcoded USERS/SOURCES arrays for real API calls and keep the interaction design; this is the smallest step in the list.
8. Observability. Logging for every register read and write (Section 15 A09) shipped before go-live, not retrofitted after an incident asks for it.
9. Testing. Extend the jsdom smoke-test pattern (Section 14) into real integration tests against a test database and mocked connector APIs, plus a contract test per connector so a source-system schema change fails a test run instead of silently breaking a production sync.
10. Rollout. Follow Section 5's calendar, but its Phase 1 ("Inventory & tagging") now means something concrete: point Connector #1 at a read replica of the HR system and validate its diff against the manual baseline before anything downstream trusts it.

18 Local vs. remote — a multi-perspective challenge

Section 3's architecture put an "on-prem register" box next to the credential vault, largely because several of its sources are on-prem. That's not the same claim as "the register application itself must run on-prem" — and it deserves to be argued with, not assumed. Below, six stakeholders who'd actually be affected by that decision each get to challenge it on their own terms. Where a challenge has a real answer, it's given; where it doesn't, that's stated plainly rather than talked around.

19 Physical / building access control

A badge that still opens a door after someone's left is the exact same governance failure as a SaaS account that's never revoked — it needs an owner, a ticket, a review cadence, and automatic revocation on offboarding, same as everything in Section 7's schema. Most of this program's design (connectors, orphan detection, offboarding fan-out, review cadence) already generalizes to physical access without new concepts — what it needs is its own source-type entry and one hard boundary the other integrations don't have to worry about.

Common systems and how they're actually reached

The one boundary that doesn't apply anywhere else in this program

Extending the data model

Physical access becomes a fourth asset category alongside hardware, licenses, and platform access — same schema (Section 7), same account-type tagging (Section 14's SSO/shared-local/service pattern extends naturally: a personal badge is "SSO-equivalent," a shared contractor/visitor badge is "shared-local"):

Where it plugs into what's already here

• Offboarding fan-out (FR-8): badge deactivation joins the auto-revoke bucket for API-capable systems, or the manual checklist bucket (physically collect the badge) for legacy DB-only deployments — exactly the same split the demo's offboarding breakdown already models for SSO vs. shared-local accounts.
• Orphan detection (Section 9): a new signal alongside the existing four — an active badge with no badge-in event in 90+ days, or one still active after an HR termination date with no matching offboarding ticket.
• Review cadence (Section 10): server-room/data-center door groups sit in the same quarterly tier as privileged local accounts; general-office door groups sit with standard SSO accounts at annual.
• Data classification (Section 15): badge-swipe history combines identity, timestamp, and location — more sensitive than any one of those alone, and a stronger case for the need-to-know principle than most logical-access data. Swipe-event history should be visible to security/facilities roles specifically, not to every admin of the register by default.
• Scope statement (Section 15): same boundary already drawn for IAM/PAM — this program is not a physical access control system and never operates door hardware; it reads from one, the same way it reads from Entra or Workday, and stops at reporting.

20 Component architecture & deployment

A working sketch of the components, corrected and filled in against everything Sections 1–19 already established, plus a concrete deployment topology and realistic data-volume numbers.

Correcting and completing the component list

Proposed deployment topology

Read-only today, write-path deferred

Data volume & retention sizing

Worth sizing concretely rather than leaving as a vague scaling worry — the numbers below are for the 100–300 user range this document scopes to (Section 2), including the 2–3× multiplier for non-human identities that section already calls out.

The corrective worth stating plainly: the identity/access register itself stays small — tens of megabytes even after years of growth, at this user scale — so it is not a big-data problem and doesn't need special storage tooling. The line item that actually grows is the tool's own access/audit logging, and that's a log-management decision (retention window, hot/cold tiering, structured log storage separate from the relational register tables) rather than a database-sizing problem for the register. "More users" mostly means more viewers generating more log lines, not a bigger register — plan retention and read-replica capacity around that distinction, not around identity-record count.

21 Independent audit — config, backups & standards gap report

Reviewed as an auditor would: against NZISM, ISO/IEC 27001:2022 Annex A, and SOC 2 Trust Services Criteria. Every line below is marked by what is actually evidenced in this document and the prototype, not by what a well-run program of this kind would eventually have — this is a design-stage audit of a specification, not an operational audit of a running system, and the finding for almost every unmet control is "not yet built," not "built and failing."

Configuration management — new, previously absent from this document

Every prior section describes what the system should do; none specify how its own configuration is controlled, versioned, or kept from drifting once built. That gap is real and is called out here rather than assumed away.

Backup & disaster recovery — new, previously absent from this document

This is the largest single gap this audit finds. No section in this document, including Section 20's database design and Section 20's retention table, specifies how the register's own data is backed up, where those backups live, or how a restore would be tested. A retention policy (how long history is kept) is not a backup capability (whether that history survives a database failure, a ransomware event, or a bad migration) — this document currently has the first without the second.

ISO/IEC 27001:2022 Annex A — representative control gap table

Annex A has 93 controls across four themes (Organizational, People, Physical, Technological). The table below is not exhaustive — it selects the controls most directly relevant to this tool's actual design and attack surface, in the same spirit as Section 15's OWASP mapping, rather than reproducing the full standard.

SOC 1 — relevance to financially-relevant access controls

SOC 1 (SSAE 18) reports on internal controls over financial reporting (ICFR) — it is the relevant frame whenever this register governs access to systems that touch financial data (an ERP, a billing platform, a payroll system) rather than general IT access. Framed differently from SOC 2: SOC 2 asks "is the system secure," SOC 1 asks "can a financial auditor rely on this system's access controls when forming an opinion on the financial statements."

SOC 2 Trust Services Criteria — gap table

NZISM alignment — themes, not control numbers

Consolidated finding — what is actually missing, ranked

Collapsing the tables above into one ordered list, an auditor's actual punch list for this program before it could pass a real readiness assessment:

1. Backup, restore, and disaster recovery — no design exists yet. The single largest gap across all three frameworks. Needed: backup schedule and encryption, an offsite/immutable copy, a restore-testing cadence, and stated RPO/RTO targets, for both the register database and the secrets manager it depends on.
2. Configuration management and change control — no design exists yet. Needed: an infrastructure-as-code baseline, a named hardening standard, drift detection, and a change-approval process distinct from Section 12's access-request ticketing.
3. Incident response and breach notification — no design exists yet. Needed: a documented escalation path and notification process specifically for this tool, given it aggregates identity/access data from many systems and is itself an attractive breach target.
4. Vulnerability management — no design exists yet. Needed: patching cadence, dependency/SAST scanning, and a disclosure process for the app layer and connector code.
5. Active security monitoring — logging exists, alerting does not. Needed: correlation/alerting on the access-log data Section 15 already requires be collected, so anomalous use of the tool itself is detected rather than only retrospectively reviewable.
6. Encryption key management lifecycle — distinct from credential rotation, currently unaddressed. Needed: a stated approach to encryption-at-rest key generation, storage, and rotation, separate from the connector-credential rotation runbook Section 16 already covers well.
7. Third-party/vendor risk assessment — no design exists yet. Needed: a lightweight due-diligence step (security questionnaire or SOC 2 report review) before onboarding a new SaaS connector, distinct from the technical connector contract Section 16 already specifies.
8. DSAR / right-to-erasure handling — principle-level only. Needed: a concrete process for handling an individual's request to see or remove their own data from the register, beyond the general retention/deletion statement already in Section 15.

Set against that list, the genuinely strong areas of this document are worth naming too, since an audit that only lists gaps is as misleading as one that only lists strengths: access control, least-privilege data collection, and data confidentiality controls are substantively designed in real, checkable detail (Sections 4, 8, 11, 15, 16, 19), well ahead of where most programs are at this stage of maturity. The gaps above are concentrated almost entirely in operational resilience (backup/DR, config management, incident response) rather than in the access-governance domain this program was actually built to address — which is the expected shape of a gap analysis for a tool that was designed access-first.

22 Full-application threat model (STRIDE)

Section 16 threat-modeled the data collection points specifically. This extends that same rigor across every trust boundary in the application — the browser, the app/API layer, the database, the admin/auditor role split, and the ticket/alert write-path — using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) so no category of risk is skipped by only thinking about the parts already discussed.

Trust boundaries in scope

• Boundary 1 — Browser ↔ Nginx. Anonymous internet/corporate-network traffic meets the first component that terminates TLS.
• Boundary 2 — Nginx ↔ App/API layer. Reverse proxy hands a request to the stateless application that enforces RBAC.
• Boundary 3 — App/API layer ↔ Database. The only component with a database connection, per Section 20.
• Boundary 4 — App/API layer ↔ Secrets manager. Runtime credential issuance for every connector.
• Boundary 5 — App/API layer ↔ Connectors / on-prem agent. Inbound diffs from every data source, covered in depth in Section 16.
• Boundary 6 — App/API layer ↔ Jira/Slack. The tool's only outbound write path to systems it doesn't own.
• Boundary 7 — Admin user ↔ Auditor user. Two roles of the same tool, differing only in write privilege (Section 11).

STRIDE, applied per boundary

23 OWASP re-verification & SAMM maturity

Two passes: first, a direct bad-practices scan of this design against common real-world OWASP findings (independent of the Top 10 category mapping already done in Section 15, since a category mapping can pass on paper while a specific bad practice still slips through); second, an OWASP SAMM (Software Assurance Maturity Model) maturity rating, because Section 15's OWASP Top 10 table answers "are the ten categories addressed" while SAMM answers the different question "how mature is the process that keeps them addressed over time."

Bad-practices scan

Common, specific anti-patterns that a Top 10 category mapping can miss because they're implementation details, not categories. Each is checked against this design directly.

OWASP SAMM maturity assessment

SAMM rates process maturity on a 0–3 scale per practice (0 = not performed, 1 = ad hoc, 2 = documented and repeatable, 3 = measured and continuously improved). Rated here against what this document currently establishes as process, not against an operating program — consistent with Section 21's stated audit scope.

24 Hardening reference — hashing, TLS, CORS, Nginx, redundancy, backups

Concrete configuration, closing the gaps the bad-practices scan (Section 23) and the audit (Section 21) just found. Where Sections 15/16/20 stated a principle ("use TLS," "hash credentials"), this section gives the actual parameters a build team would implement against.

Credential hashing

Most identities in this design are SSO-federated (Section 4) — this tool never sees, let alone stores, the password. Hashing applies specifically to the local/shared-service accounts Section 4 already acknowledges exist (shared local logins, service accounts) where this tool or its directory is the credential's actual store.

TLS configuration

CORS policy

Nginx reference configuration

A representative hardened server block — the concrete artifact Section 20's "Nginx: TLS termination, security headers, rate limiting" line was pointing at.

Notes on the choices above: Cache-Control: no-store is set globally, closing the Section 22 information-disclosure finding about cached authenticated data; proxy_ssl_verify on closes the Section 22 finding about the internal Nginx-to-app-layer hop; the rate-limit zone gives the concrete mechanism behind Section 22's DoS mitigation, tuned per expected legitimate traffic (10 requests/sec/IP is a starting point, not a fixed answer — real tuning needs production traffic data this document doesn't have yet).

Redundancy

Backups — concrete configuration, closing the Section 21 gap

25 Documentation & SOPs — starter set

Section 21 marked several controls "not evidenced" specifically because no documented process exists yet, not because the underlying idea was missing. This section turns each of those into a named, ownable document with a stated purpose, trigger, and evidence output — the starter scaffolding a program owner would fill in and operate, not the SOPs themselves in full.