Secure SDLC and Change Management Policy

1. Scope

All Vortex IQ source code, infrastructure-as-code, AI prompts and configurations that affect the platform or customer environments.

2. Secure development

• Version control. All code is held in version control with protected main branches.
• Peer review. Changes require review and approval by a second engineer before merge.
• Secrets management. Secrets are never committed to source; they are held in a managed secrets store.
• Dependency and static analysis. Dependencies are scanned for known vulnerabilities and static analysis runs in the pipeline.
• Least privilege. Build and deploy systems use scoped, audited credentials.

3. Testing

• Automated tests run in the pipeline before release.
• Security-relevant changes receive additional review.
• Changes are validated in a staging environment that mirrors production before they reach production.

4. Roles and Responsibilities

• Environment separation. Development, staging and production are separated; no untested change is promoted directly to production.
• Approval. Production changes are approved and recorded, with the change, author and approver logged.
• Customer-facing deployments. Where Vortex IQ deploys code, themes or data changes into a customer's environment, the change is staged and tested first (StagingPro, DryRunPro) and can be reverted in one click (RollbackPro). Nothing reaches a customer's production without the appropriate approval.
• Emergency changes. Expedited changes follow a defined break-glass process and are reviewed retrospectively.
• Rollback. Every production change has a defined rollback path.

5. AI and model changes

Changes to models, prompts or autonomous behaviour that affect customer-facing output follow this policy and the AI and Model Governance Policy, including evaluation before release.

6. Audit

Change records, approvals and deployment logs are retained and available for audit.