Information Security Policy
Owner: Security. Review cadence: annual or on material change. Approver: CEO.
This is the top-level information security policy for MeterBox. It is
deliberately short. The constituent procedures it names — incident response,
DR drill, access review, vulnerability disclosure, audit trail — are
documented separately and linked from the Related docs
section. An auditor reads this policy to understand what we commit to; they
read the procedures to verify we do it.
1 — Purpose + scope
MeterBox processes customer billing and metering data on behalf of tenants.
This policy defines how the company protects the confidentiality, integrity,
and availability of that data, the systems that handle it, and the
information assets used by the company to operate.
Applies to: all employees and contractors; all production systems (control
plane, data plane, off-cluster backup mirror, supporting Kubernetes
infrastructure); all repositories under the MeterBox organization; all
laptops and accounts issued for company use.
Does not apply to: a tenant's own end-customers (the tenant is the
controller; we are the processor — see privacy page).
2 — Roles + responsibilities
- CEO — owns this policy. Approves material changes. Sign-off on policy
exceptions (§ 12).
- Security lead — drafts + maintains this policy and the constituent
procedures. Runs the quarterly access review. Owns vulnerability triage.
- Engineering lead — owns change management (§ 6) and the production
access controls (§ 5). Quarterly reviewer for the access-review snapshot.
- On-call — runs the incident response plan
for whatever rotation week they hold.
- SRE — runs the quarterly DR restore drill.
Owns secret rotation cadence (§ 8).
- Every employee + contractor — completes the security training in § 10
on hire and annually. Reports suspected incidents per the IR plan.
3 — Information classification
| Tier |
Examples |
Handling |
| Public |
Marketing pages, OpenAPI spec, README, public docs |
No restrictions. |
| Internal |
Internal runbooks, design docs, employee directory |
Company accounts only. Not posted externally. |
| Confidential |
Tenant billing data, end-customer PII, audit logs, source code, financial records |
Production access requires least-privilege role + MFA. Logged in the audit trail. |
| Restricted |
Cryptographic keys, secrets, KMS material, tenant DPAs, signed contracts |
Sealed-secret or KMS-wrapped storage. Access logged and alerted on. Never in chat, ticket, or repo. |
Data covered by the privacy page is at
minimum Confidential; tenant-supplied AES keys and KMS unwrap policy are
Restricted.
4 — Acceptable use
- Workstations are company-managed: full-disk encryption on, screen lock ≤ 5
minutes, OS + browser kept current.
- Production credentials live only in a managed password manager + the
cluster's secret store. Never in personal accounts, plain files, shell
history, or chat.
- AI / LLM tooling: Restricted data never leaves the cluster. Confidential
data may only be sent to LLMs the company has reviewed and which carry
a no-training clause. The MeterBox Advisor egress is the only documented
Confidential-data path and is off by default per tenant (
enterprise_advisor_enabled).
- Personal devices may access company chat + email. They may not hold
production credentials, customer data, or Restricted material.
5 — Access control
- All company accounts require MFA (TOTP minimum; WebAuthn / passkeys
encouraged). The MeterBox dashboard enforces MFA for owner + admin via
the existing TOTP + WebAuthn flows.
- Production access is least-privilege. The role matrix lives in
/cp/rbac/matrix; owner is implicit, admin/member are tenant-configurable.
- Quarterly access review — Security lead runs
GET /cp/access-review
(CSV) for every tenant + the internal cluster; flagged stale members are
removed within 14 days. See access review snapshot
CC6.2 / CC6.3 evidence row.
- Onboarding — manager creates company accounts, requests least-privilege
role grants in writing, schedules training (§ 10) within 14 days of start.
- Offboarding — manager revokes accounts on last day. Security lead
confirms revocation within 24 hours and runs an off-cycle access review
snapshot to catch lingering grants.
- Shared admin keys carry the
X-Operator-Id header so audit attribution
survives shared credentials.
6 — Change management
- All production changes ship via pull request against the protected
main
branch. Branch protection is configured per CONTRIBUTING.md.
- Required CI gates: lint, test suite, dependency audit, Trivy scan,
CHANGELOG entry, build.
- One reviewer minimum; security-relevant PRs (auth, RBAC, audit, secrets,
encryption) require Security lead review.
- Production deploys are observable via the audit log + structured logs;
emergency deploys still PR + merge through
main and are post-reviewed
within 24h.
7 — Vulnerability management
npm audit + Trivy run on every PR + nightly on main. Critical findings
open a Sev-1 follow-up; High findings open a Sev-2 patched within 7 days;
Medium within 30 days.- External vulnerability reports come through the
vulnerability disclosure policy;
acknowledgement SLAs and safe-harbor terms are documented there.
- Annual external penetration test per
penetration-testing.md. Findings tracked to
closure.
8 — Secret management + cryptography
- No plaintext secrets in the repository. Repo-side secret scanning runs on
every PR.
- Production secrets live in the cluster's secret store (sealed-secrets or
the cloud-native equivalent). Rotation cadence documented in
operator-runbook.md § 1.5.
- Tenant-supplied AES keys for the backup mirror are stored on the org
record and never returned by
GET /cp/me. KMS-mode targets use
envelope encryption: a per-snapshot ephemeral DEK wrapped by the
customer's KMS; plaintext DEK exists only in process memory long enough to
encrypt one tarball. See audit-trail-architecture.md.
- Approved primitives: AES-256-GCM for symmetric encryption at rest; TLS
1.2+ for transport; SHA-256 for hashing; Argon2id for password hashing.
FIPS-validated builds are a roadmap item (see README).
9 — Asset management
- Workstation inventory maintained by the Engineering lead.
- Production assets — Kubernetes clusters, off-cluster buckets, KMS keys,
domains — tracked in the operator runbook.
- Source-code dependency inventory is the lockfile + the Trivy SBOM; reviewed
on every release.
10 — Security training
- Every employee + contractor completes a security awareness module within
14 days of start, covering: this policy in summary, phishing recognition,
acceptable use, incident reporting, the IR plan summary.
- Annual refresher every fiscal year. Completion logged.
11 — Vendor + subprocessor management
- Every subprocessor requires a Data Processing Agreement (DPA) executed
before it sees Confidential data.
- The public subprocessor list at /subprocessors
is the source of truth for what's currently in use. Material changes are
notified to tenants ≥ 30 days in advance per Art. 28(2) GDPR.
- Vendor risk review before onboarding any new subprocessor that will
handle Confidential or Restricted data: security posture, DPA, data
residency, breach notification SLA, sub-subprocessor list.
12 — Policy exceptions
A documented, time-bounded exception may be granted by the CEO when a
business need conflicts with this policy. Each exception records: scope,
rationale, compensating controls, owner, expiry date. Exceptions are
reviewed quarterly and not auto-renewed.
13 — Review + version control
- This policy is reviewed annually or on material change. The Last reviewed
date is updated on each review.
- Material changes go through PR review + CEO sign-off and are noted in
CHANGELOG.
Last reviewed: 2026-06-04
Related docs