Hoofdstuk 1 — Inleiding: SOC 1 in een Kubernetes-context

Waar SOC 2 vooral draait om beveiliging, beschikbaarheid en vertrouwelijkheid in brede zin, richt SOC 1 zich specifiek op één vraag: heeft een serviceorganisatie de interne controles op orde die relevant zijn voor de financiële verslaggeving van haar klanten? Voor organisaties die een betaalplatform, factureringssysteem, payroll-verwerking of andere financieel-relevante dienst draaien op Kubernetes, OpenShift of NKP, is dit vaak minstens zo belangrijk als SOC 2 — en wordt het in de praktijk regelmatig verward met SOC 2, terwijl de scope en het publiek wezenlijk anders zijn.

Dit boek behandelt SOC 1 vanuit hetzelfde technische perspectief als het SOC 2-boek in deze reeks: hoe vertaal je een auditstandaard die oorspronkelijk voor financiële processen is ontworpen, naar concrete configuratie en bewijsvoering in een containerplatform?

Zoals ook bij SOC 2 geldt: dit boek is een technisch-architecturale gids, geen vervanging voor begeleiding door een gekwalificeerde auditor. SOC 1-attestatie wordt uitgevoerd volgens de SSAE 18-standaard door een onafhankelijke auditor.

Hoofdstuk 2 — Wat is SOC 1? SSAE 18, ICFR en Type I versus Type II

SOC 1 is gebaseerd op de SSAE 18-standaard (Statement on Standards for Attestation Engagements No. 18) van de AICPA en beoordeelt Internal Control over Financial Reporting (ICFR): de controles bij een serviceorganisatie die van invloed zijn op de juistheid van de financiële verslaggeving van haar klanten (de "user entities").

Het onderscheid tussen Type I en Type II is identiek in opzet aan SOC 2: een Type I-rapport beoordeelt of controles op een specifiek moment correct zijn ontworpen; een Type II-rapport beoordeelt of die controles gedurende een observatieperiode ook daadwerkelijk consistent hebben gewerkt.

Een organisatie kan beide rapporten nodig hebben: SOC 1 omdat een klant het nodig heeft voor de eigen jaarrekeningcontrole, en SOC 2 omdat andere klanten willen weten hoe er in algemene zin met beveiliging wordt omgegaan.

Hoofdstuk 3 — SOC 1 versus SOC 2: verschillende doelen, dezelfde infrastructuur

Een cruciaal inzicht voor platformteams: de onderliggende technische infrastructuur — RBAC, wijzigingsbeheer via GitOps, monitoring, back-up — hoeft niet dubbel te worden ingericht voor SOC 1 én SOC 2. Beide steunen op dezelfde IT General Controls (ITGC). Het verschil zit in:

• Scope-afbakening — SOC 1 kijkt alleen naar systemen en processen die financieel-relevant zijn; SOC 2 kan een bredere scope hebben, inclusief systemen zonder directe financiële impact.
• Applicatiecontroles — SOC 1 vereist aanvullend bewijs over de juistheid, volledigheid en tijdigheid van financiële transactieverwerking, iets wat bij SOC 2 geen rol speelt.
• Segregation of duties — SOC 1 legt sterkere nadruk op functiescheiding rond financiële processen dan SOC 2 doorgaans doet.

Hoofdstuk 4 — IT General Controls (ITGC): de technische ruggengraat van SOC 1

ITGC's zijn de generieke, systeembrede controles die de betrouwbaarheid van alle applicaties eronder ondersteunen — zonder solide ITGC's is geen enkele applicatiecontrole houdbaar, ongeacht hoe goed die op papier is ontworpen. De vier klassieke domeinen:

• Toegangsbeheer — wie kan bij welke systemen en data, en hoe wordt dat periodiek herzien?
• Wijzigingsbeheer — hoe worden wijzigingen aan systemen die financiële data verwerken, geautoriseerd, getest en doorgevoerd?
• Computer operations — hoe worden geplande taken (batchverwerking, taakplanning) betrouwbaar uitgevoerd en gemonitord?
• Back-up en herstel — hoe wordt financiële data beschermd tegen verlies, en is herstel aantoonbaar getest?

De hoofdstukken 7 tot en met 15 van dit boek werken elk van deze domeinen in detail uit, specifiek toegespitst op Kubernetes/OpenShift/NKP.

Hoofdstuk 5 — Applicatiecontroles: waar SOC 1 verder gaat dan ITGC

ITGC's alleen zijn onvoldoende voor SOC 1: de auditor beoordeelt ook applicatiecontroles — de specifieke, geautomatiseerde of handmatige controles binnen een applicatie die de juistheid van financiële verwerking waarborgen.

• Invoervalidatie — worden financiële invoergegevens (bedragen, rekeningnummers, valuta) gevalideerd vóór verwerking?
• Volledigheidscontroles — wordt gegarandeerd dat alle transacties die het systeem binnenkomen, ook daadwerkelijk worden verwerkt (geen "stille" verliezen)?
• Nauwkeurigheidscontroles — kloppen berekeningen (bijvoorbeeld btw, valutaconversie, rente) consistent en reproduceerbaar?
• Autorisatiecontroles — worden transacties boven een bepaalde drempel expliciet goedgekeurd vóór verwerking?
• Interfacecontroles — als data tussen microservices of systemen wordt uitgewisseld, komt wat verzonden wordt overeen met wat ontvangen wordt (reconciliatie)?

Hoofdstuk 6 — Segregation of duties in een Kubernetes-omgeving

Segregation of duties (functiescheiding) is een van de meest getoetste SOC 1-controles: voorkomen dat één persoon voldoende rechten heeft om een financiële fout of fraude te veroorzaken én te verhullen.

In een Kubernetes-context vertaalt dit zich naar concrete RBAC-ontwerpprincipes:

• Een developer die code schrijft voor een betaalservice, mag niet ook de productiedatabase van diezelfde service rechtstreeks kunnen wijzigen.
• Degene die een pull request goedkeurt, mag niet dezelfde persoon zijn die de wijziging heeft ingediend (technisch afdwingbaar via branch protection-regels in de Git-repository).
• Toegang tot secrets die financiële systemen ontsluiten (databasewachtwoorden, betaal-API-sleutels), is beperkt tot een klein, expliciet gedocumenteerd team — niet het volledige ontwikkelteam.
• Wie de CI/CD-pipeline configureert, is niet automatisch dezelfde persoon die productiewijzigingen goedkeurt.

Hoofdstuk 7 — Toegangscontrole voor financieel-relevante systemen

Toegangsbeheer voor SOC 1 volgt dezelfde technische mechanismen als bij SOC 2 (RBAC, centrale identity-provider, periodieke reviews — zie ook het SOC 2-boek in deze reeks), maar met een striktere scope-afbakening: welke namespaces, services en databases worden als "financieel-relevant" aangemerkt, en is de toegang daartoe aantoonbaar beperkter dan tot de rest van het platform?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: betaalengine-productie
  name: financieel-operator
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list", "watch"]
  # Nadrukkelijk GEEN 'secrets' of 'configmaps' met schrijfrechten hier

Een periodieke toegangsreview specifiek voor financieel-relevante namespaces — los van de algemene RBAC-review — is vaak een expliciete SOC 1-vereiste, juist omdat de gevolgen van te ruime toegang hier direct financiële impact kunnen hebben.

Hoofdstuk 8 — Change management en de vier-ogen-eis voor financiële systemen

Net als bij SOC 2 is GitOps een natuurlijke match voor SOC 1-wijzigingsbeheer, met één aanvullende eis: voor financieel-relevante systemen moet de goedkeurende partij aantoonbaar niet dezelfde persoon zijn als de indiener. Dit is technisch af te dwingen via branch protection-regels in Git (bijvoorbeeld GitHub/GitLab "require review from someone other than the author").

branch_protection:
  branch: main
  required_reviews: 1
  require_review_from_code_owners: true
  dismiss_stale_reviews: true
  restrict_who_can_push: ["platform-leads"]
  allow_self_approval: false

allow_self_approval: false is hier de sleutel — zonder deze instelling kan een enkele ontwikkelaar in theorie zijn eigen wijziging goedkeuren, wat de hele segregation-of-duties-controle ondermijnt.

Hoofdstuk 9 — Computer operations: batchverwerking, taakplanning en monitoring

Veel financiële processen draaien niet continu, maar als geplande batchtaken: nachtelijke afstemming van transacties, maandelijkse facturatie, periodieke rentecalculaties. SOC 1 vereist bewijs dat deze taken betrouwbaar en volledig worden uitgevoerd.

• CronJobs met monitoring — een Kubernetes CronJob die faalt zonder alertering, is een blinde vlek in de financiële verwerking. Koppel elke financieel-relevante CronJob aan expliciete monitoring van start, voltooiing en foutstatus.
• Idempotentie — een batchtaak die na een storing opnieuw wordt gestart, mag transacties niet dubbel verwerken. Dit is een technisch ontwerpprincipe, maar wordt door auditors als applicatiecontrole getoetst.
• Volledigheidsverificatie — na afloop van een batchrun: klopt het aantal verwerkte records met het aantal aangeboden records?

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nachtelijke-afstemming
  namespace: betaalengine-productie
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 3600
      template:
        spec:
          restartPolicy: Never

Hoofdstuk 10 — Data-integriteit en processing-integriteitscontroles

Waar SOC 2 optioneel "Processing Integrity" als Trust Services Criterion kent, is een vergelijkbare mate van nauwkeurigheid voor SOC 1 vrijwel altijd verplicht wanneer financiële transacties worden verwerkt.

• Checksums en reconciliatie — vergelijk periodiek de som van verwerkte bedragen tussen bronsysteem en doelsysteem; een verschil duidt op een verwerkingsfout die direct financiële impact heeft.
• Transactielogboek — elke financiële mutatie moet herleidbaar zijn tot een bronrecord, inclusief tijdstip en verantwoordelijke actor (mens of systeem).
• Onveranderlijkheid van historische records — reeds verwerkte, financieel-relevante records mogen niet stilzwijgend worden overschreven; correcties horen als nieuwe, herleidbare mutaties te worden vastgelegd (vergelijkbaar met een boekhoudkundige correctieboeking, niet een overschrijving).

Hoofdstuk 11 — Interface- en integratiecontroles tussen microservices

Een moderne, op Kubernetes gebaseerde financiële applicatie bestaat zelden uit één monolitische applicatie, maar uit meerdere microservices die onderling data uitwisselen (bijvoorbeeld: een orderservice, een betaalservice en een boekhoudservice). Elke overdracht tussen deze services is een potentieel controlepunt.

• Berichtcompleetheid — als de betaalservice een event publiceert naar een message queue, verwerkt de boekhoudservice dat event gegarandeerd (at-least-once of exactly-once semantiek, afhankelijk van het ontwerp)?
• Schema-validatie — voorkom dat een gewijzigd berichtformaat in de ene service stilzwijgend tot verkeerde interpretatie in een andere service leidt (bijvoorbeeld een bedrag dat per ongeluk als string in plaats van decimaal wordt geïnterpreteerd).
• Reconciliatierapportage — een periodiek geautomatiseerd rapport dat aantoont dat het aantal en de som van berichten tussen twee services overeenkomt.

Hoofdstuk 12 — OpenShift-specifiek: SCC, Compliance Operator en ITGC-bewijs

De platformspecifieke voordelen van OpenShift die in het SOC 2-boek zijn besproken (Security Context Constraints, ingebouwde OAuth-server, de Compliance Operator) zijn even relevant voor SOC 1: ze leveren hetzelfde soort geautomatiseerd ITGC-bewijs, nu toegespitst op de namespaces die als financieel-relevant zijn aangemerkt.

Specifiek voor SOC 1 is het aan te raden om Compliance Operator-scans te segmenteren per scope: draai een scanprofiel gericht op de financieel-relevante namespaces apart van de bredere clusterscan, zodat een auditor direct het relevante bewijsdossier kan raadplegen zonder door irrelevante bevindingen buiten de SOC 1-scope te hoeven zoeken.

Hoofdstuk 13 — Kubernetes-specifiek (vanilla): zelf in te richten ITGC's voor SOC 1

Zoals bij SOC 2 geldt: vanilla Kubernetes vereist meer eigen inrichting dan OpenShift of NKP. Voor SOC 1 komt daar een extra aandachtspunt bij: omdat de scope beperkt is tot financieel-relevante systemen, is nauwkeurige namespace- en label-discipline extra belangrijk om te kunnen aantonen wélke controles wel en niet binnen de SOC 1-scope vallen.

• Gebruik consistente labels (bijvoorbeeld compliance-scope: soc1-icfr) op elke namespace, deployment en NetworkPolicy die binnen de SOC 1-scope valt.
• Bouw scanning- en logging-tooling zodanig dat rapportages gefilterd kunnen worden op deze labels, zodat auditbewijs specifiek voor de ICFR-scope kan worden gegenereerd zonder handmatig te hoeven scheiden.
• Documenteer expliciet de scope-afbakening zelf: welke namespaces/services zijn wel en niet meegenomen in de SOC 1-boordeling, en waarom.

Hoofdstuk 14 — NKP-specifiek: multi-cluster consistentie voor financiële workloads

Voor organisaties die financiële workloads over meerdere clusters draaien (bijvoorbeeld gescheiden per regio vanwege lokale regelgeving), biedt NKP's centrale multi-cluster console een vergelijkbaar voordeel als bij SOC 2: consistente policy-distributie en afwijkingsrapportage over clusters heen.

Specifiek voor SOC 1 is het van belang dat de scope-afbakening (welke clusters/namespaces vallen onder de ICFR-beoordeling) net zo consistent wordt toegepast als de technische policy's zelf — een cluster dat per ongeluk buiten de reguliere governance-scope valt, kan een onopgemerkt gat in de ITGC-dekking betekenen.

Hoofdstuk 15 — Back-up, herstel en continuïteit van financiële data

Verlies van financiële transactiedata heeft directe gevolgen voor de juistheid van de financiële verslaggeving van klanten — een back-up-strategie voor SOC 1-relevante systemen verdient daarom extra zorgvuldigheid ten opzichte van algemene systeembackups.

• Kortere RPO voor transactiedata — waar een algemene applicatie mogelijk een RPO van enkele uren kan accepteren, is voor financiële transacties vaak een veel kortere RPO (of zelfs synchrone replicatie) nodig om dataverlies van reeds verwerkte transacties te voorkomen.
• Geteste restore specifiek voor financiële data — een restore-oefening moet expliciet aantonen dat financiële records na herstel consistent en volledig zijn, niet alleen dat het restore-proces technisch "geslaagd" rapporteert.
• Retentie in lijn met financiële bewaarplicht — houd rekening met wettelijke bewaartermijnen voor financiële administratie, die vaak langer zijn dan een reguliere technische back-up-retentie.

Hoofdstuk 16 — Sub-service organisaties en de carve-out versus inclusive-methode

Vrijwel elke Kubernetes-gebaseerde omgeving leunt op sub-service organisaties: een clouddienst, een managed database, of de leverancier van de Kubernetes-distributie zelf. SOC 1 kent hiervoor twee erkende methoden:

• Carve-out methode — de sub-service organisatie en haar controles worden buiten de scope van het eigen SOC 1-rapport gehouden, maar wel expliciet benoemd. De auditor van de klant moet dan zelf (aanvullend) vertrouwen ontlenen aan het eigen rapport van die sub-service organisatie.
• Inclusive methode — de controles van de sub-service organisatie worden wél meegenomen in het eigen rapport, wat een nauwere samenwerking met die leverancier vereist tijdens de auditvoorbereiding.

De meeste organisaties kiezen carve-out voor grote, gevestigde cloudproviders — die publiceren doorgaans toch al hun eigen SOC 1/SOC 2-rapporten, waarnaar simpelweg verwezen kan worden.

Hoofdstuk 17 — Complementary User Entity Controls (CUECs)

Een SOC 1-rapport bevat vrijwel altijd een sectie met Complementary User Entity Controls (CUECs): controles die de serviceorganisatie verwacht dat de klant zelf (de "user entity") heeft ingericht, omdat de serviceorganisatie deze niet kan garanderen.

Voorbeelden van CUECs relevant voor een Kubernetes-gebaseerd financieel platform:

• De klant beheert zelf de toegang van zijn eigen medewerkers tot het klantportaal, inclusief het tijdig intrekken van toegang bij uitdiensttreding.
• De klant controleert periodiek de juistheid van gerapporteerde transacties in zijn eigen administratie tegen de door het platform aangeleverde rapportages.
• De klant configureert zelf welke gebruikers geautoriseerd zijn om betalingen boven een bepaalde drempel goed te keuren binnen zijn eigen organisatie.

Hoofdstuk 18 — Continu bewijs verzamelen voor een SOC 1 Type II-traject

Net als bij SOC 2 vereist een SOC 1 Type II-rapport bewijs over de volledige observatieperiode. Voor SOC 1 komt daar specifiek bewijs bij over applicatiecontroles en segregation of duties, naast de reguliere ITGC-evidence:

1. Automatiseer reconciliatierapportages (bijvoorbeeld dagelijks) in plaats van deze pas rond de audit handmatig te reconstrueren.
2. Bewaar goedkeuringshistorie van financieel-relevante wijzigingen (wie diende in, wie keurde goed, wanneer) gestructureerd en doorzoekbaar.
3. Documenteer elke uitzondering op segregation of duties (bijvoorbeeld door personeelstekort) met de toegepaste compenserende controle.
4. Bouw, net als bij SOC 2, een centraal dashboard dat de status van alle ITGC- en applicatiecontroles binnen de SOC 1-scope toont.

Hoofdstuk 19 — Praktijkcasus: een fictief betaalplatform bereidt zich voor op SOC 1

Ter illustratie: "PayVoorbeeld B.V." verwerkt betalingen namens klanten op een OpenShift-cluster, en moet voor het eerst een SOC 1 Type II-rapport opleveren voor een grote klant die dit nodig heeft voor de eigen jaarrekeningcontrole.

Scope-afbakening

Het platformteam bakent eerst expliciet af welke namespaces, services en databases binnen de ICFR-scope vallen: de betaalengine, de reconciliatieservice en de bijbehorende databases. Interne tools zonder financiële impact (zoals een interne documentatiewiki) vallen nadrukkelijk buiten scope.

Segregation of duties hersteld

Een gap-analyse onthult dat twee senior developers zowel code voor de betaalengine schrijven, hun eigen pull requests kunnen goedkeuren (self-approval stond nog aan), én rechtstreekse productiedatabase-toegang hebben. Alle drie worden binnen één maand hersteld: self-approval wordt uitgeschakeld, rechtstreekse databasetoegang wordt vervangen door een geautomatiseerde, gelogde beheerinterface, en een derde, onafhankelijke reviewer wordt toegevoegd aan het team.

Applicatiecontroles versterkt

Een dagelijkse geautomatiseerde reconciliatie tussen de betaalengine en de boekhoudservice wordt ingericht, met alertering bij elk verschil groter dan een vooraf vastgestelde materialiteitsdrempel. Na de eerste maand blijkt dit al twee keer een klein, onschuldig maar reëel synchronisatieprobleem aan het licht te brengen — precies het soort vroege detectie die de controle moet leveren.

Aan het einde van de zes maanden durende observatieperiode beschikt PayVoorbeeld over een consistent bewijsdossier: goedkeuringshistorie, dagelijkse reconciliatierapportages, en een gedocumenteerde, herstelde segregation-of-duties-structuur.

Hoofdstuk 20 — Conclusie en vervolgstappen

SOC 1 vraagt, net als SOC 2, om een combinatie van solide technische ITGC's en gedisciplineerde processen — met als onderscheidende factor de nadruk op financiële juistheid, volledigheid en functiescheiding.

1. ITGC's (toegang, wijzigingsbeheer, operations, back-up) vormen een gedeeld fundament met SOC 2 — bouw dit één keer, goed, en hergebruik het voor beide rapportages.
2. Applicatiecontroles en segregation of duties zijn het onderscheidende, aanvullende aandachtsgebied van SOC 1.
3. Scope-afbakening (welke namespaces/services zijn financieel-relevant) is cruciaal en moet consistent worden toegepast in labels, RBAC en rapportages.
4. Sub-service organisaties vereisen een expliciete keuze (carve-out of inclusive) en bijbehorende documentatie.
5. CUECs verduidelijken waar de eigen verantwoordelijkheid ophoudt en die van de klant begint.

De aanbevolen eerste stap: voer een scope-afbakening en gap-analyse uit specifiek gericht op financieel-relevante systemen, en behandel segregation of duties als eigen, expliciet controlegebied naast de reguliere RBAC-inrichting.

Bijlage A — Mapping: ICFR-controlegebieden naar Kubernetes-mechanismen

Bijlage B — Glossarium

Bijlage C — Auditvoorbereidingschecklist

C.1 Scope

• Zijn alle financieel-relevante namespaces/services expliciet geïdentificeerd en gelabeld?
• Is de scope-afbakening gedocumenteerd en beargumenteerd?

C.2 Toegang en segregation of duties

• Is self-approval van pull requests uitgeschakeld voor financieel-relevante repositories?
• Heeft niemand tegelijk schrijf-, goedkeurings- én uitvoerrechten op dezelfde financiële wijziging?
• Is toegang tot financiële secrets beperkt tot een klein, gedocumenteerd team?

C.3 Applicatiecontroles

• Zijn er geautomatiseerde reconciliatierapportages tussen gekoppelde services?
• Is invoervalidatie aantoonbaar aanwezig voor financiële velden?
• Worden dead-letter-queues gemonitord?

C.4 Computer operations

• Zijn alle financieel-relevante CronJobs gekoppeld aan monitoring en alertering?
• Is idempotentie van batchverwerking geverifieerd?

C.5 Sub-service organisaties

• Is expliciet gekozen voor carve-out of inclusive per sub-service organisatie?
• Zijn actuele attestatierapporten van sub-service organisaties verzameld (bij carve-out)?

C.6 CUECs

• Zijn CUECs concreet en toetsbaar geformuleerd?
• Zijn CUECs gecommuniceerd naar klanten die het rapport gebruiken?

Bijlage D — Aanbevolen bronnen

• AICPA SSAE 18 — de officiële standaard waarop SOC 1-attestaties zijn gebaseerd.
• AICPA Guide: Reporting on Controls at a Service Organization — praktische richtlijnen voor SOC 1-rapportage.
• Het SOC 2-boek in deze reeks — voor de gedeelde ITGC-basis (toegang, netwerksegmentatie, versleuteling, monitoring).
• COSO Internal Control - Integrated Framework — veelgebruikt raamwerk voor het structureren van interne controles.

Dit boek is bedoeld als technisch-architecturale gids, niet als vervanging voor begeleiding door een gekwalificeerde auditor of compliance-specialist. Betrek bij een daadwerkelijk SOC 1-traject altijd een ervaren auditor om de exacte scope, materialiteitsdrempels en interpretatie van ICFR voor de eigen organisatie te bepalen.