Internal Tool Security Checklist: Before Employees Use It

# Internal tool security checklist

Use this with a named security or product reviewer before launch and after material change. Record `pass`, `gap`, `not applicable`, or `needs specialist review` for each item, with evidence, owner, and due date. This worksheet is not a penetration test, threat model, compliance certification, or legal opinion.

Do not put secrets, tokens, personal data, customer confidential data, production credentials, or exploitable configuration details in this document.

## Review record

- Tool and version:
- Accountable service owner:
- Security or product reviewer:
- Business decision owner:
- Data and actions in scope:
- Environments in scope:
- Review date and next review trigger:

## Identity and authorization

- [ ] Every person and service authenticates with its own identity.
- [ ] Ordinary operation does not use shared human accounts.
- [ ] Access is denied by default and explicitly granted by role.
- [ ] Record, field, function, and action permissions are reviewed separately.
- [ ] Administrative, bulk, sensitive, financial, destructive, and irreversible actions receive stronger controls.
- [ ] Service identities and permissions are separated by environment.
- [ ] Dormant accounts, roles, delegated approvals, sessions, and service accounts are reviewed and revoked.
- [ ] Authorization is enforced at the server or action boundary, not only hidden in the interface.

## Secrets and credentials

- [ ] Secrets are stored in a controlled secret manager, not source code, examples, tickets, or logs.
- [ ] Access to secrets is limited, monitored, and assigned to an owner.
- [ ] Rotation and emergency revocation are documented and tested.
- [ ] Credentials have the minimum records, functions, actions, duration, and environment scope.
- [ ] Departing users and retired services trigger credential and access review.

## Data

- [ ] Every data field has a business purpose and named source owner.
- [ ] Collection and display are limited to the minimum necessary data.
- [ ] Sensitive data is classified, masked where appropriate, and protected in transit and at rest.
- [ ] Retention, deletion, export, backup, and legal-hold duties are recorded.
- [ ] Production data and credentials do not enter development or test without explicit approved protection.
- [ ] Prompts, examples, model inputs, outputs, traces, logs, notifications, and exports follow the same data rules.

## Actions and approvals

- [ ] Required inputs, current state, version, and authority are checked immediately before an action.
- [ ] Approvers see the exact proposed action, target, evidence, uncertainty, expiry, and effect.
- [ ] Approval is bound to the exact version and scope and expires after material change.
- [ ] Stable business keys, idempotency where supported, rate limits, value limits, and scope limits constrain effects.
- [ ] Destination state is verified; timeout-after-possible-effect routes to reconciliation before retry.
- [ ] Rollback, compensation, containment, and manual fallback are defined for applicable effects.

## Logging and monitoring

- [ ] Authentication, denied authorization, sensitive configuration changes, administrative actions, approvals, attempted effects, failures, and corrections are recorded.
- [ ] Logs exclude secrets and minimize personal or confidential content.
- [ ] Log access, export, retention, integrity, and deletion are controlled.
- [ ] Alerts have a named recipient, immediate action, severity, and duplicate-suppression behavior.
- [ ] Business outcomes and confirmed external effects are monitored, not only technical completion.
- [ ] The team can reconstruct intent, version, inputs, decision, authority, effect, error, repair, and outcome.

## Secure development and change

- [ ] Security requirements and a risk-based threat review are current.
- [ ] Source, build systems, artifacts, deployment credentials, and production configuration are protected from unauthorized change.
- [ ] Dependencies, provenance, vulnerabilities, versions, notices, and support windows are tracked.
- [ ] Authorization, validation, logging, secrets, failure paths, and security controls have tests.
- [ ] Releases and AI instructions are versioned with review, test evidence, approval, rollout scope, verification, and rollback or fallback.
- [ ] Corrected failures become regression cases before changed behavior is released.
- [ ] Material feature, data, integration, permission, model, or infrastructure changes trigger another review.

## Incident readiness

- [ ] A contact and escalation path exists outside the tool.
- [ ] The team has exercised containment, credential revocation, effect reconciliation, evidence preservation, fallback, notification, and recovery.
- [ ] Incident roles and decision authority are named.
- [ ] Legal, privacy, customer, employee, insurer, and regulatory notification duties are identified where applicable.

## Offboarding and retirement

- [ ] Human access, groups, roles, delegated approvals, and sessions are removed promptly.
- [ ] Credentials available to a departing person are reviewed and rotated or revoked.
- [ ] Sole ownership of repositories, deployment, alerts, documentation, and fallback is transferred.
- [ ] Retirement stops triggers and jobs, reconciles open work, exports required data, preserves required evidence, revokes identities and secrets, and notifies users.

## Findings

| Control or gap | Status | Evidence location | Owner | Due date | Verification |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## Release decision

- Approved scope:
- Conditions before release:
- Accepted residual risks and accountable owner:
- Required specialist reviews:
- Release approver:
- Next review date or material-change trigger: