OPERATING POLICIES · REVISION 1.1
Rules for authorized, traceable, and recoverable operation.
These policies define permitted use of NBS, identity and access requirements, data classification and handling, retention, change control, incident reporting, connector governance, enforcement, and approved exceptions.
1. Acceptable Use Policy
Permitted use
NBS may be used only for assigned operational, reliability, security assurance, governance, support, and review duties. Access must remain within the identity's authorized role and the resource scope associated with the work.
Prohibited use
- sharing credentials, MFA values, session cookies, recovery references, or service secrets;
- attempting to bypass role, CSRF, origin, rate, retention, approval, or maintenance controls;
- retrieving, changing, or exporting information outside an assigned operational purpose;
- performing denial-of-service tests, credential stuffing, destructive testing, or unapproved automation;
- placing live credentials, private keys, personal data, or tenant secrets into resource names, incident notes, screenshots, or exports;
- representing NBS documentation as evidence of a certification, audit, provider affiliation, or legal commitment not explicitly stated.
Automation
Automated access requires an approved service identity, bounded rate, documented owner, defined purpose, and an error strategy that does not retry denied or conflicting operations indefinitely. Interactive credentials must not be embedded in scripts.
2. Access Control Standard
Each person uses an individually assigned identity. Shared interactive accounts are prohibited. Roles must reflect current duties and must be reviewed when team, responsibility, employment, or support scope changes.
| Requirement | Standard | Evidence |
|---|---|---|
| Authentication | Assigned username and password; MFA for privileged roles | Authentication audit outcome |
| Least privilege | Role limited to required functions | Role assignment and access review |
| Privileged access | No credential sharing; changes recorded by actor | Session and mutation audit |
| Review | Quarterly for privileged roles; annual for other active roles | Access review case and due date |
| Revocation | Remove access promptly when no longer required | Account and session revocation record |
Read-only roles may inspect approved views and evidence but cannot perform mutations. Disabling a control in the interface is not considered sufficient enforcement; the API must deny the operation independently.
Emergency authority must be time-bound, attributable, approved through the incident command path, and reviewed after use. It must not rely on shared credentials or unrecorded changes.
3. Data Classification and Handling Standard
| Class | Examples | Handling |
|---|---|---|
| Public | Published documentation, status, security.txt | May be shared without authentication; accuracy review required |
| Operational | Region health, capacity, resource names, incidents, changes | Restricted to assigned duties; avoid unnecessary external sharing |
| Confidential | Identity assignments, audit exports, recovery cases, internal topology | Approved storage, need-to-know access, bounded retention |
| Secret | Passwords, MFA secrets, session cookies, private keys, provider credentials | Never place in NBS content or exports; use approved secret storage only |
A record inherits the highest classification of the information it contains. Adding secret material to an operational field does not make the field an approved secret store. Exports must be stored and deleted according to their review purpose.
Resource naming
Resource names must use service or function identifiers and must not include personal data, customer names, credentials, case details, or private tenant identifiers. Names are validated to lowercase letters, numbers, and hyphens.
4. Data Retention Standard
Retention balances traceability, security investigation, operational need, and data minimization. The record owner is responsible for applying any approved hold and documenting deviations from the default.
| Record class | Default | Owner | Disposition |
|---|---|---|---|
| Interactive sessions | 12 hours; 30 days when remembered | Identity Operations | Expire and remove server record |
| MFA challenges | 5 minutes or successful use | Identity Operations | Remove from active memory |
| Recovery cases | 90 days after closure | Identity Operations | Delete unless security hold applies |
| Authentication audit | 365 days | Security Assurance | Delete after retention and hold check |
| Control mutation audit | 365 days | Platform Governance | Delete after retention and hold check |
| Service health history | 90 days | Global Reliability | Aggregate or delete |
| Change and incident record | 365 days after closure | Global Reliability | Archive or delete by review requirement |
| Audit export | Until assigned review completes | Exporting reviewer | Secure deletion from review location |
Holds and backups
An incident, investigation, or applicable requirement may suspend ordinary deletion for a defined record set. Holds must identify owner, scope, reason, approval, and review date. Recovery backups follow a bounded rotation; expired records may remain until the backup containing them is rotated.
5. Change Management Standard
Material production changes require a defined request, owner, purpose, affected services, risk, planned window, validation method, and recovery action. The requester and approver must be distinct when two-person approval is required.
- Plan: define the intended outcome, dependencies, risk, and rollback.
- Review: verify scope, safeguards, active incidents, and maintenance conflicts.
- Approve: authorize only the documented scope and window.
- Execute: use an assigned identity and preserve request IDs.
- Validate: check health, state, listener ownership, and relevant objectives.
- Close: record result, deviations, and follow-up actions.
An approval does not authorize expanded scope. When observed conditions differ materially from the plan, stop and submit an amended request unless incident command explicitly invokes the emergency path.
Release changes
Control-plane releases require a successful build, API tests, consistent database backup, application and origin backup, health validation, and confirmation that existing gateway services, interfaces, transport ports, and firewall rules remain unchanged.
6. Incident Reporting Standard
Report an event when there is confirmed or suspected unauthorized access, loss of control-plane integrity, material service interruption, persistent objective breach, secret exposure, or failure of a security safeguard.
Initial reports should include UTC time, affected component, request or resource ID, observed behavior, impact, and current containment. Do not include active credentials or copy unrelated audit data.
| Severity | Illustrative condition | Response |
|---|---|---|
| SEV-1 | Widespread control loss, active compromise, or severe availability impact | Immediate command and containment |
| SEV-2 | Material regional or control-plane degradation | Immediate investigation and mitigation plan |
| SEV-3 | Limited impact with a viable workaround | Assigned owner and monitored remediation |
| SEV-4 | Minor defect or risk without current service impact | Normal backlog and scheduled correction |
Public status communication is based on confirmed user-visible impact. Security investigations may remain restricted while evidence is validated.
7. Integration Governance Standard
Every connector registration requires an owner, purpose, least-privileged service identity, approved secret location, endpoint scope, rotation method, health signal, and removal procedure. Browser-visible configuration must use aliases and exclude credentials and private tenant identifiers.
Provider names and documentation links are technical references. They must not be used to imply partnership, certification, sponsorship, or audit. External assurance requires separate published evidence with scope and date.
- Secrets must be stored outside static assets and browser responses.
- Connection tests must not expose credentials or unrestricted network details.
- Degraded connectors require an owner and operating impact assessment.
- Unused registrations must be disabled and removed through change control.
8. Enforcement and exceptions
Access may be restricted or suspended when activity creates material security, privacy, integrity, or availability risk. Enforcement actions must be attributable and proportionate and should preserve evidence required for investigation.
Exceptions
An exception must identify the policy requirement, business need, affected assets, risk, compensating controls, owner, approver, start date, expiry, and review date. Open-ended exceptions are not permitted. Expired exceptions are treated as noncompliance until renewed or remediated.
Reporting concerns
Security concerns follow the vulnerability disclosure process. Access, privacy, and policy questions should use the registered support channel associated with the assigned identity.