Governance, Risk & Compliance

Alright. Let's talk about the question that shows up in every serious RFP:

"Are you ISO certified?"

Before anyone asks that out loud, we need to answer the harder one internally:

"Do we actually behave like a company that could pass an audit, or do we just have a slide that says security?"

This doc is Volume 0 for GRC. Scope, risk appetite, ISO alignment, physical security, secure SDLC, and something I care about personally: we do not stop at locking doors. We measure whether people and systems still behave under pressure, and we watch attacks in real time so we learn faster than the next incident teaches us the hard way.

Full disclosure: I am, at core, a security person. GRC is not paperwork I tolerate so engineering can ship. It is how a hosting company earns the right to hold customer DNS, billing data, and platform access. HostKid documents that posture before we have a certificate on the wall.

---

Why a mini host still needs GRC thinking

HostKid holds:

• Customer credentials and data
• Billing and identity information
• DNS (mistake equals outage or hijack)
• Email (abuse potential and deliverability reputation)
• Physical access to the gear that runs the factory floor

Even a lab company documents how it would behave at production maturity. That is the DevSecOps instinct: traceable decisions, not "we will secure it later."

---

ISO 27001 is the spine (everything else hangs off it)

Framework	What it gives us	HostKid use
ISO/IEC 27001	Information Security Management System (ISMS)	Primary alignment target. Scope, control map, risk register, management review.
ISO/IEC 22301	Business continuity	DR, backup strategy, restore drills. Volume 27.
ISO/IEC 20000	IT service management	Support, change, incident process. Volumes 23, 27.
SOC 2 (Type II)	Trust for B2B buyers (US-heavy)	Future if we sell to SaaS/agencies at scale

ISO is not a PDF binder. It is a loop: assess risk → pick controls → operate them → measure → fix gaps → repeat. If a control exists only in Notion, it does not exist.

---

Physical security (the rack is in scope)

People love to talk about zero trust in Kubernetes and forget the datacenter door.

For HostKid, physical controls are first-class ISO themes, not a footnote:

Control area	Executive intent	Proof we expect
Facility access	Only authorized people touch racks, keys, and remote hands tickets	Access logs, visitor policy, escort rules where colo requires it
Asset handling	Servers and disks are tracked from purchase to decommission	Asset register, wipe certificates before resale or scrap
Network perimeter	Firewall, segmentation, out-of-band management not exposed to the internet by accident	Diagram + rule review. Volume 5, Volume 22.
Environmental	Power, cooling, and cable discipline are availability and safety	Colo SLA, capacity planning in Volume 27

---

Secure SDLC (SSDLC): build security in, do not bolt it on

HostKid ships software: portal, APIs, provisioning engine, automation. Secure SDLC means security is a gate in the pipeline, not a panic meeting the week before launch.

Phase	What we enforce (executive level)	Handbook home
Design	Threat sketch for new flows (auth, billing webhooks, provision jobs)	Vol 0 architecture, Vol 20 APIs
Build	Dependency scanning, secret scanning, code review with security checklist	Vol 21 automation, Vol 22
Test	SAST/DAST where appropriate, staging that mirrors prod auth and TLS	Vol 22, Vol 27
Deploy	Signed artifacts, GitOps, no manual prod SSH as default path	Vol 7 IaC, Vol 21
Operate	Patch cadence, vuln SLAs, logging, incident hooks	Vol 17, 18, 27

No feature ships because "it works on my laptop." It ships when we can answer: who can abuse it, what breaks if it fails, and what log proves who did what.

---

AI velocity vs code quality (we are not anti-AI, we are anti-trash)

Let me say this plainly because the industry is split into two useless camps right now.

Camp one: "Never use AI, real engineers type every line." That is nostalgia, not strategy.

Camp two: "Ship faster, vibe-code everything, fix security later." That is how you get a portal that demos beautifully and explodes in production because the base layer had SQL injection, hardcoded secrets, and copy-paste auth logic nobody read.

HostKid is in camp three:

Use AI as a productivity multiplier. Never use AI as an excuse to skip engineering discipline.

AI compresses time to market. That is real. You can scaffold APIs, tests, Terraform modules, and boilerplate in hours instead of days. But the same tool can produce massive volumes of plausible garbage: spaghetti architecture, inconsistent patterns, subtle vulnerabilities baked into "working" code, and dependencies nobody audited because the diff was too long to review with human eyes.

We are not refusing the mindset of coding with AI. We are refusing the fantasy that generation replaces governance. The how is SSDLC enforced end to end, from architecture to commit, with automated gates that fail the pipeline when quality or security regresses.

The guardrails (architecture → commit → prod)

Stage	What AI must not bypass	Enforcement examples
Architecture	Threat sketch, data flow, trust boundaries before "generate the service"	ADR or design note linked in MR. Vol 0 + Vol 20 sign-off for sensitive flows
Local / pre-commit	Secrets and obvious foot-guns never enter Git	Gitleaks, lint, formatter, unit tests on changed paths
Merge request	Human review on security-sensitive diffs, even if AI wrote 90%	CODEOWNERS, checklist: auth, input validation, logging, error handling
CI pipeline	Static analysis, dependency risk, container hygiene	SonarQube (quality + security hotspots), SAST (Semgrep/Trivy as needed), SBOM, license checks
Staging	Behavior matches prod TLS, auth, and config	DAST on exposed routes, integration tests, provision smoke paths
Prod promotion	ISO-aligned release evidence, not "green button because demo worked"	Change record, rollback plan, vuln SLA clear, signed artifacts / GitOps only

AI writes drafts. Engineering owns merges. The person accepting the MR is accountable, not the model. If you cannot explain what the code does under audit, it does not ship, no matter how fast it was generated.

What we explicitly reject

Anti-pattern	Why it dies here
10k-line AI dump, zero review	Unreviewable attack surface. Split, review, test, or delete.
Skipping tests "because AI added them later"	Later never comes. Tests gate the merge.
Disabling SonarQube / SAST to go green	Documented exception only, with owner and expiry.
Prod hotfix outside GitOps	Speed without traceability is how base code gets exploited quietly.
"Security will harden in Volume 22"	Volume 22 implements. Volume 0 and SSDLC block weak code at the door.

Pipeline templates, tool versions, and MR checklists: Volume 21 (Automation) and Volume 22 (Security). This section states the executive rule: productivity without quality is debt with a chatbot face.

---

The security department never stops learning (and we test people on purpose)

Policies on a wiki do not equal culture. HostKid's security posture assumes humans are part of the attack surface and training decays the moment life gets busy.

If nobody fails a simulation, the simulation was too easy. We want a department that treats learning and being tested as normal ops, the same way we treat patch Tuesday.

---

Securing alone is not enough: see attacks while they happen

Here is the mindset shift I keep pushing:

Hardening without visibility is hope.

You can patch, segment, MFA everything, and still get surprised because the internet is loud. Attackers scan constantly. Bots hammer SSH. Credential stuffers hit login forms. Mail abuse probes exist 24/7.

A mature host does two things in parallel:

1. Prevent what we can (controls, SSDLC, physical security, identity).
2. Observe what still reaches the edge, classify it, and feed dashboards leadership and engineering actually open.

That second lane is why Executive metrics & SLOs and this GRC doc shake hands. Metrics are not only revenue and provision time. They include attack volume, top source countries, alert categories, and whether our detections are getting smarter.

---

Cyber deception: after we secure, we deliberately bait

Passive defense is necessary. It is not sufficient.

Once baseline controls exist, HostKid adopts cyber deception: honeypots, canary tokens, and decoy surfaces that look real to attackers but exist only to generate intelligence. Every touch becomes a lesson: new scan pattern, new exploit attempt, new malware sample, new geo trend.

Defense alone is no longer enough. Attackers only need to be right once. Deception turns their curiosity into our telemetry.

---

T-Pot CE: our honeypot platform of record (lab → production path)

For the deception layer, we standardize on T-Pot CE from Deutsche Telekom Security: an all-in-one, multi-arch multi-honeypot platform that runs 20+ honeypot personalities behind Docker, feeds the Elastic Stack, and ships visualization tooling out of the box.

Why T-Pot for HostKid:

Reason	What it gives us
Breadth	Cowrie, Dionaea, Conpot, Honeytrap, and many others in one compose stack
Visualization	Elastic Stack dashboards plus live attack map options
Operational fit	Docker-native, matches how we already think about platform services
Threat intel loop	Feeds IoC lists, firewall rules, and Volume 22 detections over time

Executive rollout phases:

1. Lab T-Pot on isolated hardware: validate resource needs (plan for 8 to 16 GB RAM, 128 GB disk, open outbound internet for updates).
2. Dashboards wired into our monitoring story (Volume 17): attack categories, source countries, top ports targeted.
3. Playbooks: when a novel pattern spikes, who gets paged, what gets blocked at the edge, what gets ticketed for Volume 22.
4. Production deception mesh: multiple sensors, not one lonely VM, aligned with ISO incident management themes.

Implementation detail lands in Volume 22. This page states why it exists and that it is mandatory direction, not a cool GitHub project for weekends.

---

Live attack monitoring (what "good" looks like on screen)

Until our own T-Pot and SIEM dashboards are fully wired, we still hold the bar visually: leadership should be able to open one view and see the noise on the wire, not guess.

The screenshot below is Sicherheitstacho (Deutsche Telekom Security's public attack-speedometer style view): real-time attack arcs on a world map, alert categories in the last 60 seconds, source and target country rollups, and a live alert feed. It is the vibe we want internally: attacks listed, categorized, geolocated, and scrolling, not buried in raw syslog.

Loading media

If you cannot show me today's attack picture, you are not ready to tell a customer you are "monitoring 24/7." T-Pot gets us there. Grafana and Loki get us platform health. Together they answer what is hitting us and what is breaking us.

---

ISMS scope (draft)

In scope (HostKid):

• Customer portal and APIs
• Provisioning engine and automation pipelines
• CloudStack management plane and hypervisor hosts
• DNS, email, billing integrations
• Monitoring, logging, backup systems
• Support tools and knowledge base
• Physical colo footprint and rack assets
• Deception infrastructure (T-Pot and successors)
• People processes: onboarding, offboarding, security exercises

Out of scope (initially):

• Customer content inside VMs (customer responsibility; see Security posture)
• Third-party registrar internals (supplier risk only)

Scope gets a formal statement before any real certification attempt.

---

Risk appetite (executive)

Area	Appetite	Rationale
Platform outage	Low	Core revenue driver
Data breach (our systems)	Very low	Existential trust hit
Undetected attack activity	Very low	We deploy deception + monitoring to shrink this
Provisioning delay	Medium-low	SLO-backed, not zero
Experimental features in prod	Low	Use lab/staging
Vendor dependency	Medium	Document supplier risk
Failed phishing simulation	Medium (managed)	Expected; drives training, not blame

---

Risk register (format)

Every serious host maintains a register. Our columns:

Field	Example
Risk ID	R-2026-014
Description	Compromised admin portal account
Impact	High. Customer data exposure
Likelihood	Medium
Owner	Security / founder
Mitigation	MFA, RBAC, audit logs, deception intel (Vol 9, 22)
Residual risk	Low after controls
Review date	Quarterly

Living register grows in Volume 22; executive template lives here.

---

ISO 27001 control mapping (executive)

Map themes to handbook volumes. Implementation detail elsewhere:

ISO 27001 theme	Executive intent	Handbook home
Organizational controls	Policies, roles, supplier risk, management review	Vol 0, 27
People controls	Hiring/termination hygiene, awareness, phishing exercises	Vol 0, 9
Physical controls	Colo access, asset lifecycle, rack security	Vol 27, Vol 22
Technological controls	Crypto, logging, vuln mgmt, backup, SSDLC	Vol 22, 18, 17, 21
Access control	Least privilege, MFA, SSO	Vol 9, 22
Operations security	Change mgmt, capacity, malware, honeypots / deception	Vol 21, 27, 22
Incident management	Detect, respond, learn, attack dashboards	Vol 23, 27, 17
Business continuity	Backups, DR tests	Vol 6, 27
Supplier relationships	Registrar, payment gateway, upstream, colo	Vol 0, 11

---

Governance habits

• Quarterly risk register review with deception and exercise results on the agenda
• Change advisory for production platform (lightweight at first; Volume 27)
• Documented exceptions with expiry dates (temporary risk accepts are not permanent folklore)
• Supplier review when billing, DNS, registrar, or colo vendors change
• Security exercise calendar: phishing tests, tabletops, restore drills (at least one meaningful test per quarter)
• Attack dashboard review: monthly leadership glance at T-Pot / SIEM rollups alongside executive metrics

---

What this doc does not cover

Topic	Where it lives
Vault policies, firewall rules, CrowdSec	Volume 22
T-Pot install YAML, VLAN IDs, honeypot tuning	Volume 22
Audit log retention config	Volume 18
Pen test reports	Future ops doc / Volume 27
Customer-facing trust copy	Security & trust posture

---

The GRC stack in one breath

Preparing diagram

---

Next: Security & trust posture. Customer promise and shared responsibility.