Implements the change-management requirements of the Operations Security Policy.

​
Standard change

  1. Plan & assess. Document purpose, specification, dependencies, and rollout plan in the PR description.
  2. Authorize. Approving review on the PR (see Code Review). For substantial changes, also notify the system owner or the CTO.
  3. Communicate. For changes affecting external partners or customers, post in #releases at least 5 business days in advance (shorter for emergency changes per the Emergency change section).
  4. Test. Changes are tested in a non-production environment (staging) before production deploy.
  5. Deploy. Per the planned schedule. Deploys go through GitHub Actions.
  6. Verify. Post-deploy smoke tests, monitoring dashboards, error rates.
  7. Rollback. If the change fails or causes regression, revert via the Rollback Procedure.

​
Emergency change

Emergency changes may be expedited but must undergo retrospective review and authorization. Process:
  1. Deploy the fix.
  2. Notify engineering on-call (and the CISO if security-related) in #engineering-incidents.
  3. File the Emergency Change Retro intake form within 24 hours documenting the change, root cause, and review. A retrospective PR is opened from the same ticket.
  4. The post-hoc review captures approver and any follow-ups.

​
Change freeze for scheduled pen-tests and audits

For the duration of each scheduled penetration-test fieldwork window (per the engagement scope letter — most recently the Horizon3 2026 engagement) or SOC 2 / ISO 27001 fieldwork window, Neuroscale operates a production change freeze to prevent confounding test results:
  • Scope of freeze: non-emergency production deploys (application + infrastructure). Pre-production environments are unaffected. Customer-facing announcement is not required (the freeze is operational).
  • Duration: from the start of fieldwork to fieldwork close per the engagement letter; extensions require CTO + CISO sign-off.
  • Enforcement: (1) Linear board status — prod-freeze: active label on the Engineering project; (2) CODEOWNERS gate on prod-deploy PRs requiring CTO or CISO approval and a freeze-exception: <ticket> reference; (3) on-call engineers notified at freeze start and freeze end via Slack #engineering.
  • Exception path: P0 / P1 emergency changes follow the Emergency change procedure above; the emergency-change retrospective additionally notes “exception during scheduled change-freeze” and is reviewed at the next ISMS Management Review.
  • Documentation: the freeze start + end timestamps are committed to the Linear epic for the engagement; the exception list (if any) is referenced in the engagement’s evidence pack at SharePoint > SOC 2 > Vendor Evidence > <engagement> > Freeze-exceptions.
This procedure is the CC8.1 operating mechanism that supports the per-engagement scope letter’s “change-freeze coordination” commitment.

​
Continuity

ICT continuity plans, response procedures, and recovery procedures are kept up to date with significant changes. See Business Continuity.

​
Records

Change records (PRs, deploy history, ticket trail) are retained per the Records Retention Schedule → Security and operations (3 years) and the system-by-system Data Retention Matrix.

​
Version history

VersionDateDescriptionAuthorApproved by
1.0May 8, 2026Initial versionCameron WolfeIshan Jadhwani