Norwegian compliance — high-level gap scan (2026-05-09)
Norwegian compliance — high-level gap scan
Section titled “Norwegian compliance — high-level gap scan”Scope and caveats. This is an engineering scan, not legal advice. It identifies surface-level gaps by cross-referencing observed rig architecture against Norwegian/EEA compliance frameworks. A qualified Norwegian lawyer must verify applicability and remediation steps before any compliance claims are made.
1. Regulatory landscape (Norway-specific)
Section titled “1. Regulatory landscape (Norway-specific)”| Framework | Norwegian instrument | Regulator | Likely applicability |
|---|---|---|---|
| GDPR | Personopplysningsloven 2018 (lov 2018-06-15-38) | Datatilsynet | High — rig processes GitHub usernames, contributor content, agent memory |
| ePrivacy / cookie law | Ekomloven § 2-7b, Markedsføringsloven | Nkom / Forbrukertilsynet | Medium — public docs sites may set cookies |
| Web accessibility | Forskrift om universell utforming av IKT (WCAG 2.1 AA) | Uutilsynet | Medium — applies to private enterprises with public-facing web IKT |
| Norwegian Security Act | Sikkerhetsloven 2018 | NSM | Low — only if critical infrastructure or classified processing |
| NIS2 (in transposition) | Sikkerhetsloven revision | NSM | Low — only if essential/important service threshold met |
| Accounting / invoicing | Regnskapsloven, Bokføringsloven | Skatteetaten | Unknown — depends on entity type and commercial activity |
2. What the rig processes — personal data inventory
Section titled “2. What the rig processes — personal data inventory”Based on BRAIN.md and architecture docs:
| Data element | Where stored | Likely personal data? | Notes |
|---|---|---|---|
| GitHub usernames | Event store (PostgreSQL), PR/issue comments | Yes | Linked to real identities via GitHub profile |
| Issue / PR body text | Event store logs, agent context | Possibly | May contain names, project details, internal discussions |
| Agent memory entries | rig-memory-mcp (Postgres + pgvector) | Possibly | Entries record who wrote/assigned issues; contributor names |
| Token usage / cost data | rig-conductor PostgreSQL | Possibly | Tied to agent sessions that map to human contributors |
| Discord webhook payloads | Discord (external, US) | Possibly | Thread posts may include GitHub usernames |
| iBuild-E logs | Mac Mini in Oslo | Unknown | Local build logs; unclear if personal data retained |
3. Likely compliance gaps
Section titled “3. Likely compliance gaps”3.1 GDPR / Personopplysningsloven
Section titled “3.1 GDPR / Personopplysningsloven”| Gap | Basis | Priority |
|---|---|---|
| No privacy notice on research.rig.dashecorp.com or docs.rig.dashecorp.com | Art. 13–14 GDPR — transparency obligation | High |
| No documented lawful basis for processing contributor personal data | Art. 6 GDPR | High |
| No Records of Processing Activities (RoPA / Behandlingsprotokoll) | Art. 30 GDPR | High |
| No documented Data Processing Agreements with sub-processors | Art. 28 GDPR | High |
| No data subject rights process (access, erasure, portability) | Art. 15–22 GDPR | Medium |
| No data breach notification procedure documented | Art. 33–34 GDPR | Medium |
| No documented data retention / deletion policy for memories and event logs | Art. 5(1)(e) storage limitation | Medium |
| Cross-border data transfers undocumented (GCP, GitHub, Anthropic, Discord, Cloudflare — all US-headquartered) | Art. 46 GDPR — transfer mechanism required | Medium |
| iBuild-E on Mac Mini in Oslo: local data handling policy unknown | Art. 32 GDPR | Low/Unknown |
Sub-processors currently identified from BRAIN.md:
- Google Cloud Platform (GKE, GCE) — k3s cluster
- GitHub (issue/PR management)
- Anthropic (Claude API — LLM inference)
- Discord (webhook notifications)
- Cloudflare (Pages CDN for docs sites)
3.2 ePrivacy / cookie law
Section titled “3.2 ePrivacy / cookie law”| Gap | Basis | Priority |
|---|---|---|
| No cookie consent banner on research.rig.dashecorp.com | Ekomloven § 2-7b | Medium |
| No cookie consent banner on docs.rig.dashecorp.com | Ekomloven § 2-7b | Medium |
| Cookie inventory not documented (Cloudflare Pages, Starlight, MkDocs may set cookies) | Pre-condition for consent UI | Medium |
3.3 Web accessibility (universell utforming)
Section titled “3.3 Web accessibility (universell utforming)”| Gap | Basis | Priority |
|---|---|---|
| No accessibility statement published | IKT-forskriften § 9 | Medium |
| No WCAG 2.1 AA audit performed on either docs site | IKT-forskriften | Low |
Note: Universell utforming obligations for private enterprises apply when the IKT solution is “publicly available” (rettet mot allmennheten). If the sites are effectively internal (only accessed by Dashecorp staff and agents), this may not apply — needs legal confirmation.
4. Observations: what partially covers these areas
Section titled “4. Observations: what partially covers these areas”- rig-gitops whitepaper/security.md — discusses internal security posture; no mention of GDPR or data subject rights.
- rig-gitops whitepaper/trust-model.md — covers agent trust boundaries, not external personal data handling.
- No existing privacy, compliance, or legal docs found in any rig repo.
5. Smallest useful TaskSpec
Section titled “5. Smallest useful TaskSpec”Data flow inventory + controller identification
Before any remediation, the team needs a factual inventory of:
- What personal data flows through the rig, from where to where.
- Which legal entity is the data controller (requires confirming Dashecorp’s Norwegian entity status).
- Which third parties are processors vs. independent controllers.
This one-doc output unblocks: RoPA authorship, DPA procurement, privacy notice drafting, and transfer mechanism selection. Without it, subsequent tasks have no grounding.
Estimated effort: 1–2 days (human lead + agent research support).
Output: docs/data-flow-inventory.md in rig-gitops.
6. Follow-up questions required before deeper work
Section titled “6. Follow-up questions required before deeper work”- Legal entity: Is Dashecorp a Norwegian AS (aksjeselskap), NUF, sole trader, or another structure? Norwegian law applies differently to each.
- Site audience: Are research.rig.dashecorp.com and docs.rig.dashecorp.com intended for public access or restricted to Dashecorp personnel? (Determines ePrivacy and universell utforming scope.)
- Data subjects: Does the rig process personal data of anyone other than Dashecorp’s own employees or contractors? (E.g., open-source contributors whose GitHub activity is indexed.)
- GCP region: Which GCP region hosts the k3s cluster? (Determines if processing is EEA-local or a cross-border transfer.)
- Existing DPAs: Are Data Processing Agreements already signed with Google Cloud, GitHub, and Anthropic? (Enterprise/business accounts typically include standard DPAs; individual accounts may not.)
- DPO / privacy lead: Is there a designated Data Protection Officer or privacy-responsible individual?
- Mac Mini in Oslo: Does iBuild-E retain logs or personal data locally, or does all data flow to the cluster?
- Commercial activity: Does Dashecorp have paying customers or users? (Affects scope of Regnskapsloven, Markedsføringsloven, and potentially Forbrukertilsynet oversight.)
7. Recommended immediate low-effort steps (pre-legal review)
Section titled “7. Recommended immediate low-effort steps (pre-legal review)”These are low-risk documentation steps that do not require legal sign-off but are prerequisites for any formal compliance effort:
| Action | Effort | Unblocks |
|---|---|---|
| Draft data flow inventory (see §5) | 1–2 days | Everything |
| Add “No personal data collected” notice to both docs sites if that is factually true | 2 hours | Transparency gap |
| Audit Cloudflare / Starlight / MkDocs for cookies set | 2 hours | Cookie gap |
| List all third-party services with links to their DPA/SCCs | 2 hours | Transfer gap |
| Document GCP region in BRAIN.md or infra docs | 30 min | Transfer gap |