Assenture

Change Management and Secure SDLC Policy

Last updated: August 8, 2026

This policy governs how changes to Assenture's application code, database schema, infrastructure and third-party integrations are proposed, reviewed, tested, approved, released and, where necessary, reversed. It applies to all personnel and contractors who can affect production. It is read together with our Security Policy, Access Controls Policy and Logging and Monitoring Policy.

1. Principles

  • No direct production edits. Every production change originates from version-controlled source. Manual changes in a production console are prohibited except under the emergency procedure in section 7.
  • Separation of duties. The author of a change is not its sole approver. At least one other qualified reviewer must approve before merge.
  • Traceability. Every deployed artefact maps to a commit, a reviewer, a build and a timestamp.
  • Security by design. Security review is part of the change, not a later gate.
  • Reversibility. A change is not approved unless a rollback or forward-fix path is understood.

2. Change categories

  • Standard. Pre-approved, low-risk, repeatable changes (copy edits, dependency patch bumps, non-breaking UI changes). Peer review plus automated checks.
  • Normal. Feature work, schema migrations, permission or RLS changes, integration changes. Peer review, automated checks, security review and engineering-lead approval.
  • Emergency. Changes required to restore service or remediate an active security issue. Section 7 applies.

3. Development lifecycle

  1. Plan. Work is captured as a tracked item with intent, scope and acceptance criteria before implementation.
  2. Branch. Development occurs on isolated branches; the main branch is protected and cannot be pushed to directly.
  3. Implement. Engineers follow secure coding standards: parameterised queries only, deny-by-default authorisation, input validation with schema validators, output encoding, no secrets in source, no privileged database credentials reachable from client bundles.
  4. Review. Mandatory peer review. Reviewers explicitly assess authorisation logic, tenant isolation, data exposure, input validation and error handling in addition to correctness.
  5. Test. Automated type checking, linting, unit and integration tests, and build verification run on every proposed change. Failing checks block merge.
  6. Approve. Normal changes require engineering-lead approval; changes touching authentication, authorisation, row level security, payments or financial-data integrations require an additional security review.
  7. Release. Merge to the protected branch triggers an automated, reproducible build and deployment. Deployments are immutable and versioned.
  8. Verify. Post-deployment health, error-rate and latency signals are observed. Anomalies trigger rollback.

4. Environment separation

  • Development, preview and production are separate environments with separate credentials, secrets and databases. Secrets are never shared across environments.
  • Production customer data is not copied into development or preview environments. Testing uses synthetic or anonymised data.
  • Preview deployments are generated per change so reviewers can validate behaviour before release.

5. Database and schema changes

  • All schema changes are expressed as reviewed, version-controlled migrations applied through the deployment pipeline. Ad hoc SQL against production is prohibited.
  • Every new table in the application schema must ship with explicit privilege grants, row level security enabled and reviewed policies. A migration without them is rejected at review.
  • Destructive migrations (drops, type narrowing, backfills) require explicit engineering-lead sign-off and a verified backup point before execution.

6. Dependency and supply-chain control

  • Dependencies are pinned by lockfile; builds are reproducible.
  • Automated dependency and vulnerability scanning runs against the codebase; findings are triaged by severity with remediation targets of 7 days (critical), 30 days (high) and 90 days (medium).
  • End-of-life runtimes, frameworks and libraries are tracked and replaced before or promptly after their support end date.
  • New third-party dependencies and services are assessed under our Third Party Risk Management Policy before adoption.

7. Emergency changes

  • An emergency change may bypass the normal approval queue only to restore availability or contain a security incident, and only with real-time acknowledgement from engineering leadership.
  • The change is still made through version control and the deployment pipeline wherever technically possible.
  • Retrospective peer review, documentation and, where relevant, an incident record under our Incident Response Policy must be completed within 2 business days.

8. Rollback

Deployments are versioned and immutable, so the previous known-good release can be restored. Schema migrations are written to be backward compatible with the immediately prior application version wherever feasible, so application rollback does not require a database rollback. Where that is not possible, a tested down-path or restore point is prepared before release.

9. Records and audit

  • Source history, review approvals, automated check results, build metadata and deployment events are retained as the change record and are available for audit.
  • Production configuration and infrastructure are defined declaratively in version control, so configuration drift is detectable.
  • Access to release and deployment controls is restricted to named engineers under the Access Controls Policy.

10. Ownership and review

This policy is owned by Assenture engineering leadership, reviewed and approved at least annually and after any material architecture change or security incident. Exceptions require documented approval, a compensating control and an expiry date. Questions and assurance requests: business@assenture.app.