ISMS Copilot Docs

Wijzigingsbeheerbeleid

ISMS Copilot hanteert een formeel wijzigingsbeheerbeleid om ervoor te zorgen dat alle wijzigingen aan onze productiesystemen veilig worden beoordeeld, getest en geïmplementeerd. Ons proces balanceert tussen veiligheids- en nalevingsvereisten en de behoefte aan snelle iteratie.

ISMS Copilot hanteert een formeel wijzigingsbeheerbeleid om ervoor te zorgen dat alle wijzigingen aan onze productiesystemen veilig worden beoordeeld, getest en geïmplementeerd. Ons proces balanceert tussen veiligheids- en nalevingsvereisten en de behoefte aan snelle iteratie.

Ons wijzigingsbeheerbeleid is direct geïntegreerd met onze GitHub-workflow en CI/CD-pipeline voor geautomatiseerde handhaving.

Wijzigingstypen

We categoriseren wijzigingen in drie typen op basis van risico en impact:

  • Standaardwijzigingen — Laag-risico, vooraf goedgekeurde wijzigingen zoals documentatie-updates, afhankelijkheidspatches en routinematige configuratie-updates. Deze kunnen automatisch worden samengevoegd nadat geautomatiseerde controles zijn geslaagd.
  • Normale wijzigingen — Functietoevoegingen, wijzigingen in databaseschema's, API-wijzigingen en beveiligingsupdates. Vereisen een volledig beoordelingsproces met minimaal één goedkeuring vóór implementatie.
  • Spoedwijzigingen — Kritieke beveiligingslekken, serviceonderbrekingen of problemen met gegevensintegriteit. Volgen een versneld goedkeuringsproces terwijl een audit trail en een na-implementatiebeoordeling worden gehandhaafd.

Goedkeuringsworkflow

Ons standaard wijzigingsproces volgt deze stappen:

  1. Aanmaken GitHub-issue — Wijzigingsverzoek gedocumenteerd met rechtvaardiging en impactbeoordeling
  2. Branch en pull request — Codewijzigingen ontwikkeld in feature branch met beschrijvende PR
  3. Geautomatiseerd testen — CI-pipeline voert geautomatiseerde tests uit, waaronder unittests, integratietests en beveiligingsscans
  4. Peer review — Minimaal één teamlid beoordeelt code, architectuur en beveiligingsimplicaties
  5. Goedkeuring en samenvoegen — Goedgekeurde wijzigingen worden samengevoegd met de main branch
  6. Geautomatiseerde implementatie — Wijzigingen worden automatisch geïmplementeerd in productie via onze CI/CD-pipeline (Supabase, Fly.io, Vercel)

Spoedwijzigingen volgen een versnelde route, maar handhaven nog steeds een audit trail en vereisen een na-implementatiebeoordeling binnen 24 uur.

Testen en kwaliteitscontroles

Voordat een wijziging in productie komt, dwingt onze geautomatiseerde CI-pipeline het volgende af:

  • Uitvoering van geautomatiseerde testsuite
  • Validatie van databasemigraties in de Supabase CI-omgeving
  • Statische codeanalyse en beveiligingsscans
  • Buildverificatie voor alle implementatiedoelen

Terugdraaien en herstel

Ons wijzigingsbeheerbeleid omvat terugdraaiprocedures voor mislukte implementaties. We behouden de mogelijkheid om wijzigingen snel terug te draaien terwijl de gegevensintegriteit en systeembeschikbaarheid worden gewaarborgd.

Alle wijzigingen worden bijgehouden in GitHub met een volledige auditgeschiedenis, inclusief goedkeurders, tijdstempels en rechtvaardiging van de wijziging.

Geheimen en configuratiebeheer

Wijzigingen met betrekking tot geheimen, API-sleutels of gevoelige configuratie volgen aanvullende beveiligingscontroles naast de standaard wijzigingsprocedures om blootstelling van inloggegevens te voorkomen.

On this page