By now you have a working platform with access rules generated from one matrix, a proven security suite and a runbook. To IT, though, it is a new system arriving from outside their process. Their job is to know every system on the network and accept its risk on the company's behalf. Give them what they need in the form they use, and approval becomes a review instead of an argument.

The questions IT asks

Shared responsibility

Running on Vercel and Supabase does not hand security to them. Both publish a shared responsibility model: they secure the infrastructure, the runtime and the database engine; you secure your accounts, your code, your access rules and your data ^[4][5]. IT will want to see that you know where the line is.

Evidence from the providers

For the provider layers, IT accepts independent evidence rather than your word. Ask for it early; some reports need a signed non-disclosure agreement and a few days.

Many IT teams send a security questionnaire, such as the Shared Assessments SIG ^[11] or the Cloud Security Alliance's CAIQ ^[12]. You answer for your layers; for the provider layers you attach their evidence. A complete package often replaces most of the questionnaire.

A worked example

An illustrative case, not a named plant. A 180-person plastics moulder: the plant manager sends IT a link to the platform and asks for approval. IT asks for a meeting, then sends a questionnaire of 140 questions, and three weeks pass. On the second attempt the same team sends the seven-part package below, the providers' SOC 2 reports and a one-page cover note mapping each part to NIST CSF functions. IT replies in four days with three questions, all answered in writing, and approves with one condition: a yearly re-review. The platform did not change between the two attempts; the evidence did.

Network placement

The platform has three kinds of users on the network: operator tablets on the plant Wi-Fi, office PCs and phones on the business network, and, if you planned one in Session 5B, a data connector that reads the historian. The connector belongs in the industrial DMZ (Purdue Level 3.5), the zone where every exchange between the plant and the outside stops, as in the CPwE reference design from F01 ^[1][2].

• Operator tablets are just browsers. They reach the Vercel address over HTTPS like any website. They need no access to PLCs, SCADA or the historian.
• The data connector reads from the historian inside, and writes summaries out to Supabase over HTTPS, as a dedicated database role that may insert into one table and nothing else. If it has to connect to Postgres directly rather than through the HTTPS API, check Supabase's connection page: direct connections use IPv6 by default, while the connection pooler accepts IPv4 ^[3].
• Nothing needs an inbound port. No VPN from the cloud, no port forwarding, no remote desktop into the plant. If someone proposes one, it is a separate approval.

Firewall rules: a short allow list

Cloud services change their IP addresses, so write rules 1–3 by host name (most current firewalls support host-name rules) rather than by IP. On the Supabase side, network restrictions can limit direct database connections to the company's own public IP addresses, and SSL enforcement refuses unencrypted connections; switch both on and list them in the package ^[4][5].

The data flow diagram

A data flow diagram shows every place data is entered, stored and sent, and draws trust boundaries where data passes between zones you control differently. Every flow that crosses a boundary is checked against STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) ^[6][7].

The data inventory

List every table, what it holds, its classification and where it is stored. The migrations folder already lists the tables, so this is a generated document (chapter 3). The classification decides who may see a table and whether it may leave the site.

What goes in the package

The third column labels each document with the NIST CSF 2.0 function it answers, so IT can file it ^[4]. The structure follows the familiar shape of a system security plan, the document US federal systems use to describe a system and its controls before approval ^[1]. You do not need the federal detail; IT will recognise the shape.

Generate it

Your coding agent can read the repository and write the first draft of documents 1–7 in an hour. You check every line against the platform, because the package is a statement your company makes to its own IT team. Keep the diagrams as text (GitHub draws Mermaid diagrams inside Markdown files), so a change to a flow shows up as a change to a line ^[2].

Write docs/it-package/ from this repository, one Markdown file per document:
1-system.md, 2-network-and-flows.md, 3-data-inventory.md, 4-access.md, 5-change-control.md, 6-security-evidence.md,
7-operations.md. Sources: README; supabase/migrations (every table, its columns, a proposed classification for me
to confirm); the Role and Exposure Matrix file (roles, screens, data sets); .github/workflows and the branch rules;
the latest CI results; docs/runbook.md. Draw the network placement and data flow diagram as Mermaid.
Name environment variables, never their values. Mark anything you are unsure of as TO CONFIRM.
Plain language for an IT reviewer. Open a pull request.

Keep it true: the drift check

A small script regenerates the parts of the package that come straight from code, the table list, the roles and the outside hosts the code calls, and compares them with the committed package. Run it in CI next to the OWASP suite.

// scripts/package-drift.mjs: fails when the data inventory no longer lists every table the migrations create.
import { readFileSync, readdirSync } from "node:fs";
const sql = readdirSync("supabase/migrations").map((f) => readFileSync(`supabase/migrations/${f}`, "utf8")).join("\n");
const created = new Set([...sql.matchAll(/create table (?:if not exists )?(?:public\.)?"?(\w+)"?/gi)].map((m) => m[1].toLowerCase()));
const dropped = new Set([...sql.matchAll(/drop table (?:if exists )?(?:public\.)?"?(\w+)"?/gi)].map((m) => m[1].toLowerCase()));
const tables = [...created].filter((t) => !dropped.has(t));
const inventory = readFileSync("docs/it-package/3-data-inventory.md", "utf8").toLowerCase();
const missing = tables.filter((t) => !inventory.includes(`| ${t} |`));
if (missing.length) { console.error("Not in the data inventory:", missing.join(", ")); process.exit(1); }
console.log(`Data inventory lists all ${tables.length} tables.`);

Add the same kind of check for roles (every role in the matrix appears in the access statement) and for outside hosts (every host the code calls appears in the flows document). Each check is a few lines; together they mean the package is re-reviewed exactly when it needs to be, and never otherwise.

The sign-off

Approval is a decision by a named person to accept the remaining risk on the company's behalf. NIST's risk management framework calls it authorisation, and expects it to be revisited when the system or its risks change ^[3]. Make that explicit:

• Open items and exceptions are listed in the cover note with an owner and a date (for example, "Plant Wi-Fi for tablets is not yet separated from Level 2: IT, by 30 November").
• Risks accepted are named, with the person accepting them.
• Re-review triggers are agreed: a new data flow or vendor, a new kind of data, a change of network placement, or a year passing.
• The signed version is a tagged commit in the repository, so anyone can see exactly what was approved.