# Forge NC — CAIQ v4 Self-Assessment Response

**Respondent:** Forge NC (Forge Neural Cortex), sole proprietorship in transition to LLC (Wisconsin, USA)
**Product/Service:** Forge — an AI safety, reliability, and compliance evaluation platform. Offers free local CLI (`forge-nc` via PyPI) + paid Forge Certified Audits (Startup, Enterprise) + Deployment Assessments for companies integrating LLMs into products.
**Response Date:** 2026-04-14
**Framework:** Cloud Controls Matrix (CCM) v4 / Consensus Assessments Initiative Questionnaire (CAIQ) v4
**Canonical URL:** https://forge-nc.dev/compliance/caiq_v4.pdf
**Contact:** security@forge-nc.dev

---

## Reader's Note on Honesty

This questionnaire has been answered in good faith and with direct codebase citation. Forge NC is an early-stage organization; this response reflects current state, not aspirational state. Controls marked **Yes** are implemented and verifiable in code. Controls marked **Partial** are in progress or apply only to a subset of operations. Controls marked **No** or **Not Applicable** are honestly identified as gaps or as the responsibility of third-party providers (hosting, RunPod, Cloudflare, Stripe, HuggingFace).

Forge NC's strength lies in the cryptographic verifiability of its audit deliverables (Ed25519 signing, transparency logs, offline verification by third parties using only public keys). Its weaknesses are those typical of a pre-Series-A solo-operator technology company — no SOC 2 certification yet, no formal BCR/DR program, no 24/7 monitoring. These gaps are being addressed as the roadmap executes.

Customers who require enterprise-grade operator maturity today (formal SLAs, SOC 2 Type II, ISO 27001) should wait for those milestones (see `ROADMAP.md`) or request a supplemental risk acceptance statement covering their specific concerns.

---

## Shared Responsibility Model

Forge NC operates no datacenters, no physical infrastructure, and no corporate networks. The security posture of Forge NC depends on the following third-party providers:

| Provider | Scope | Provider's Compliance Posture |
|---|---|---|
| cPanel reseller (Midphase/Hostmonster lineage) | forge-nc.dev web/DB hosting | Provider-dependent; customer should request SOC 2 or equivalent direct from provider |
| RunPod | GPU-accelerated audit worker execution | RunPod claims SOC 2 Type II |
| Cloudflare | CDN, WAF, TLS termination for forge-nc.dev | Cloudflare holds ISO 27001, SOC 2 Type II, PCI DSS, FedRAMP Moderate |
| Stripe | Payment processing | PCI DSS Level 1 (highest) |
| GitHub / GHCR | Source code repo + runner container registry | GitHub holds SOC 1 Type II, SOC 2 Type II, ISO 27001 |
| HuggingFace Hub | Model weights download (for model_weights audit path) | HuggingFace holds SOC 2 Type II |
| Discord | Community/bot hosting | Discord holds SOC 2 Type II |

Where a CAIQ control asks about physical, environmental, or infrastructure controls, the answer below references the shared-responsibility model and identifies which provider holds the primary responsibility.

---

## A&A — Audit & Assurance

**A&A-01 — Audit & Assurance Policy and Procedures**
- Status: **Partial**
- Forge NC has not published a formal written audit policy. A pre-release internal audit was conducted 2026-03-24 (see `ROADMAP.md:296`) covering 7 critical + 8 high + 10 medium issues, all remediated. No third-party external audit has been performed on Forge NC's own infrastructure.

**A&A-02 — Independent Assessments**
- Status: **No**
- Forge NC has not undergone SOC 2, ISO 27001, or any equivalent third-party assessment. SOC 2 Type I self-assessment is on the roadmap (`ROADMAP.md` Phase 4).

**A&A-03 — Risk-Based Planning Assessment**
- Status: **Partial**
- Internal risk register documented informally in `ROADMAP.md:184-196` (Risk Register section covering adoption risk, Matrix critical-mass risk, incumbent risk, single-founder risk, trademark risk, enterprise sales-cycle risk). Not a formal ISO 31000 risk management framework.

**A&A-04 — Requirements Compliance**
- Status: **Yes** (for the product); **N/A** (for the operator)
- Forge's *audit product* maps test scenarios to EU AI Act, NIST AI RMF, ISO 42001, SOC 2, and HIPAA. See `forge/assurance.py:8-17` for the protocol version constant and the per-scenario compliance mappings. NIST 800-53, CMMC 2.0, and FedRAMP mappings are planned.
- Forge NC as an operator does not currently hold any third-party compliance attestation.

**A&A-05 — Audit Management Process**
- Status: **Yes** (product); **Partial** (operator)
- Product: `server/audit_orchestrator.php` implements the webhook-driven order → dispatch → runpod_complete → origin_certify pipeline (lines 45-1197) with logging, audit state machine, and admin oversight.
- Operator: Admin audit log in database (`server/db.php` `admin_audit_log` table, written via `db_audit_log()` at `server/db.php:137-157`) records all admin actions.

**A&A-06 — Remediation**
- Status: **Partial**
- Informal via GitHub Issues + direct git commits. No formal SLA on remediation times. Security disclosures have a 14-day response commitment (see `/security-policy`).

---

## AIS — Application & Interface Security

**AIS-01 — Application Security Baseline**
- Status: **Partial**
- No formal OWASP ASVS or equivalent baseline documented. Security controls are implemented ad-hoc based on engineering judgment.

**AIS-02 — Application Security Metrics**
- Status: **No**
- No formal security metrics collection (e.g., mean-time-to-remediate, vuln backlog size).

**AIS-03 — Client-Side Input Sanitization (XSS/Injection Prevention)**
- Status: **Yes (partial coverage)**
- XSS: `htmlspecialchars()` used for user-generated content display (report_view.php, dashboard.php). No global sanitization middleware; relies on per-output encoding.
- CSRF: session-based CSRF tokens generated and validated via `hash_equals()` on sensitive endpoints — `server/account_actions.php:27`, `server/account.php:45`, `server/checkout.php:497`, `server/dashboard.php:2411`. NOT all state-changing endpoints are covered.
- Input validation: `filter_var(..., FILTER_VALIDATE_EMAIL)` at `server/checkout.php:61`; tier whitelist at `server/checkout.php:53`; account actions validate CSRF before processing.

**AIS-04 — Secure Application Design and Development**
- Status: **Partial**
- Forge NC ships two distinct protective systems under the "Crucible" brand. For transparency, both are listed with their actual scope:
  - **Forge Crucible Runtime Security Pipeline (9 layers)** — applies to the Forge CLI when a developer uses it as their local AI coding assistant. Fires on file reads, tool calls, and plan execution. Invoked only by `forge/engine.py`. Layers: Pattern Scanner (`forge/crucible.py` `_scan_static`), Semantic Anomaly (`forge/crucible.py` `_scan_semantic`), Behavioral Tripwire (`forge/crucible.py` `_check_behavioral`, HMAC-SHA512 chained provenance), Canary Trap (`forge/crucible.py` `_check_canary_in_args`), Threat Intelligence (`forge/threat_intel.py`), Command Guard (`forge/safety.py`), Path Sandbox 4-tier (`forge/resource_guard.py`), Plan Verifier (`forge/plan_verifier.py`), Forensic Auditor (`forge/forensics.py`).
  - **Forge Crucible Assurance Protocol (74 scenarios across 8 categories)** — applies during Forge Certified Audits and Deployment Assessments. Implemented in `forge/assurance.py` with per-scenario compliance mappings to EU AI Act, NIST AI RMF, ISO 42001, SOC 2, and HIPAA. This is the code path that runs inside the RunPod worker (`runpod/handler.py`) or the in-VPC external runner during a paid audit. It does not invoke the runtime pipeline above; the two systems are independent.
- Both are proprietary product IP.
- Server-side: no formal secure SDLC documented. No threat modeling artifacts in repo.

**AIS-05 — Automated Secure Application Testing**
- Status: **No** (infrastructure); **Yes** (test harness)
- No SAST/DAST/secret-scanning in CI. `.github/workflows/docker.yml` only builds containers; no security scanning step.
- Forge's own product has 1,332 pytest tests (`tests/` directory: 58 unit test files + 13 integration test files, confirmed via test count). `conftest.py` provides stub + live Ollama harnesses.

**AIS-06 — Vulnerability Remediation**
- Status: **Partial**
- Ad-hoc via git commits. No formal triage SLA other than security-disclosure commitments in `/security-policy`.

**AIS-07 — Secure Deployment**
- Status: **Partial**
- CI/CD: `.github/workflows/docker.yml` builds two Docker images (forge-audit-api slim + forge-audit-weights with vLLM) and pushes to GHCR. RunPod templates auto-update via GraphQL.
- PHP application deployment: manual SFTP via WinSCP from developer workstation to cPanel reseller. No automated deployment pipeline; no blue/green or canary rollouts.

**AIS-08 — Application Security Testing**
- Status: **Partial**
- Unit + integration tests via pytest. Integration tests include stress/chaos scenarios: crash_recovery, endurance, network_chaos, policy_drift, tool_corruption (`tests/integration/`).
- No manual penetration test has been conducted on Forge NC infrastructure. Planned for later phases.

---

## BCR — Business Continuity & Disaster Recovery

**BCR-01 — Business Continuity Management Policy**
- Status: **Partial (informal)**
- No formal written BCP. `ROADMAP.md:184-196` risk register acknowledges single-founder risk. Long-term mitigation via Perpetuity Plan (Arweave pinning + legal succession) documented in `memory/forge_perpetuity_plan.md` but not yet implemented due to funding constraints.

**BCR-02 — Risk Assessment and Impact Analysis**
- Status: **Partial**
- Risk register exists in `ROADMAP.md`. No formal Business Impact Analysis (BIA) document.

**BCR-03 — Business Continuity Strategy**
- Status: **Partial**
- Offline-verifiable certified audit artifacts: a customer's Ed25519-signed Forge Certified Audit remains verifiable using only the Origin public key, without any server call, in any language that has an Ed25519 library. This is a core design feature, not a compensating control — see `forge/external_runner_keys.py`, `server/verify_report.php`, `server/assurance_verify.php`.
- Perpetuity Plan: pinning public artifacts (Origin pubkey, transparency log archive, verifier SDK, methodology docs) to Arweave for permanent survival regardless of Forge NC's operational status. Pending revenue funding.
- Legal succession document for Origin key custody: planned, pending attorney funds.

**BCR-04 — Business Continuity Testing**
- Status: **No**
- No DR drills. Key restoration procedure documented informally (local backup of Origin seed on user desktop).

**BCR-05 — Backup Policy**
- Status: **Partial**
- Web hosting backup: hosting provider's standard cPanel backup.
- Database backup: SQLite file-based (see `server/db.php:11-27`); no scheduled export script. Provider-level file backup applies.
- Origin Ed25519 key: master copy stored offline on user's desktop (see `memory/forge_external_runner_plan.md` decision #4).
- Recovery Point Objective (RPO): not formally defined.
- Recovery Time Objective (RTO): not formally defined.

**BCR-06 — Service Recovery**
- Status: **Partial**
- Recovery relies on: (a) hosting provider restoring infrastructure, (b) user redeploying code from the public GitHub repo, (c) restoring the Origin key from local backup.
- Expected recovery time under current setup: order of hours to one business day, depending on hosting provider availability.

**BCR-07 — Incident Response Plans**
- Status: **No**
- No formal written IR plan. Informal incident response via user's direct action.

**BCR-08 — Response Plan Testing**
- Status: **No**
- No tabletop exercises performed.

**BCR-09 — Communication**
- Status: **Partial**
- Newsroom page (`/news`) planned. Email templates exist for customer audit completion notification (`server/includes/email_templates.php`). No dedicated breach notification template. No status page (e.g., statuspage.io equivalent).

**BCR-10 — Backup Documentation**
- Status: **Partial**
- Key backup procedure informally documented in `memory/forge_external_runner_plan.md`.

**BCR-11 — Redundancy**
- Status: **Limited**
- Web tier: single cPanel instance, no HA.
- Compute tier (audit workers): RunPod multi-region serverless + on-demand pods provide some resilience, but forge-nc.dev itself is a single host.

---

## CCC — Change Control & Configuration Management

**CCC-01 — Change Management Policy**
- Status: **Partial (informal)**
- No formal written change management policy. Operator follows git-based versioning + manual deployment.

**CCC-02 — Quality Testing**
- Status: **Yes (technical)**; **Partial (process)**
- 1,332 automated pytest tests cover unit + integration + stress scenarios. Tests run locally before deployment; no enforced pre-deploy test gate in CI.

**CCC-03 — Change Management Technology**
- Status: **Yes**
- GitHub (public repository at github.com/Forge-NC/Forge). Every change tracked via git commits. Docker image builds on push via `.github/workflows/docker.yml`.

**CCC-04 — Unauthorized Change Protection**
- Status: **Partial**
- Repo is public; commits are from the owner's credentials. Branch protection rules on `main` are not currently enforced (solo operator).
- Production deployment requires SFTP credentials + origin key access — single-operator control.

**CCC-05 — Change Agreements**
- Status: **N/A**
- No customers whose systems are modified by Forge NC; this control primarily applies to operators who change customer infrastructure.

**CCC-06 — Change Management Baseline**
- Status: **Partial**
- Configuration baselines exist as JSON files: `server/data/audit_config.json`, `server/data/tiers_config.json`, `forge/config.py:DEFAULTS`. No schema validation framework applied. Versioned via git.

**CCC-07 — Detection of Baseline Deviation**
- Status: **No**
- No configuration drift detection (e.g., Chef Inspec, OSQuery). Config changes are identified by git diff.

**CCC-08 — Exception Management**
- Status: **No**
- No formal exception process.

**CCC-09 — Change Restoration**
- Status: **Yes (technical)**
- Any code change is reversible via `git revert` + redeploy. Configuration changes tracked in git.

---

## CEK — Cryptography, Encryption & Key Management

**CEK-01 — Encryption and Key Management Policy**
- Status: **Partial**
- Cryptographic choices are documented in code comments. No separate written cryptography policy.

**CEK-02 — CEK Roles and Responsibilities**
- Status: **Yes (implicit)**
- Origin (owner) is the sole cryptographic authority. Documented in code and in `memory/forge_naming.md`. No formal role matrix.

**CEK-03 — Data Encryption**
- Status: **Yes**
- In-transit: HTTPS enforced site-wide via Cloudflare TLS termination. HSTS (`max-age=31536000`) enforced in `server/.htaccess`.
- At-rest (sensitive fields): Customer API keys and system_prompts encrypted via `sodium_crypto_secretbox` (XSalsa20-Poly1305) using a key derived from the Origin Ed25519 secret via BLAKE2b (`server/includes/audit_crypto.php:21-58`).
- At-rest (reports, database): **not encrypted at the storage layer** — relies on file permissions (`0600` for Origin key file; provider-level OS permissions for DB). This is a gap for customers with strict encryption-at-rest requirements.

**CEK-04 — Encryption Algorithm**
- Status: **Yes**
- Ed25519 (signatures): passport signing, report signing, external-runner child keys
- BLAKE2b (KDF): derives symmetric key from Origin seed (`server/includes/audit_crypto.php:24-25`)
- HKDF-SHA512 (KDF): derives child signing keys from Origin seed for the external-runner protocol (`forge/external_runner_keys.py:50-73`)
- XSalsa20-Poly1305 (authenticated encryption): via `sodium_crypto_secretbox` (`server/includes/audit_crypto.php:37`)
- SHA-512 (hashing): scenario hash chain, token fingerprints
- bcrypt cost 12 (password hashing): `server/auth.php:181,224`
- All algorithms are NIST/IRTF-approved; no weak or deprecated primitives in use.

**CEK-05 — Encryption Change Management**
- Status: **Partial**
- Algorithm choices are pinned in code. Changes require a code commit + deploy.

**CEK-06 — Encryption Change Cost Benefit Analysis**
- Status: **N/A**

**CEK-07 — Encryption Risk Management**
- Status: **Partial**
- Risks related to the single Origin key (non-rotatable, single point of failure) are documented in `ROADMAP.md` and `memory/forge_external_runner_plan.md`. Child-key mechanism (HKDF per-job, 24-hour validity) mitigates blast radius for audit-specific keys.

**CEK-08 — CSR (Certificate Signing Request)**
- Status: **N/A**
- Forge NC does not operate a PKI CA. TLS certificates for forge-nc.dev are managed by Cloudflare.

**CEK-09 — Encryption and Key Management Audit**
- Status: **Partial**
- Origin key usage is logged (admin_audit_log for server-side operations). No dedicated crypto-audit log.

**CEK-10 — Key Generation**
- Status: **Yes**
- Ed25519 keys generated via `cryptography` package (Python) and `sodium_crypto_sign_keypair` (PHP via libsodium). Randomness sourced from `secrets` (Python) and `random_bytes()` / `sodium_randombytes` (PHP).

**CEK-11 — Key Purpose**
- Status: **Yes**
- Documented in code and in `memory/forge_external_runner_plan.md`. Keys are domain-separated: Origin root key, machine per-install keys, external-runner child keys per-job (HKDF-derived).

**CEK-12 — Key Rotation**
- Status: **Partial**
- Origin root key: **no automatic rotation mechanism**. Manual rotation would require cross-signing the new pubkey via `/.well-known/forge-origin.json` during a grace window (planned but not implemented).
- Child keys: automatic 24-hour validity window enforced cryptographically in the envelope (`forge/external_runner_keys.py:46-64`).
- User machine keys: no rotation; persist for the life of the install.

**CEK-13 — Key Revocation**
- Status: **Yes** (child keys and passports); **No** (Origin root)
- External-runner child keys: revocable by job_id via `external_revocations.json` (`forge/external_runner_keys.py:240-262`).
- Passport revocation: `server/data/revocations.json` consulted on validation (`server/passport_api.php:347-358`).
- Origin root key revocation has no automated mechanism — a compromised root would require manual key-ceremony to publish a new pubkey.

**CEK-14 — Key Destruction**
- Status: **Partial**
- Child-key private material is derived on-demand and ephemeral (not stored beyond the enrollment bundle). Origin root key is stored on disk at `server/data/origin_key.json` and in offline backup.

**CEK-15 — Key Activation**
- Status: **Yes**
- Keys are activated on first use; Origin key loaded by `load_origin_key()` / `load_origin_pubkey()` (`server/includes/passport_signing.php:23-54`).

**CEK-16 — Key Suspension**
- Status: **Partial**
- Revocation (CEK-13) covers suspension use cases for child keys and passports.

**CEK-17 — Key Deactivation**
- Status: **Partial**
- Child keys deactivate on expiry (24h). Origin key has no automated deactivation.

**CEK-18 — Key Archival**
- Status: **Partial**
- Offline backup of Origin seed on user's desktop (documented in `memory/forge_external_runner_plan.md`). No archival vaulting service.

**CEK-19 — Key Compromise**
- Status: **Partial (documented procedure)**
- Incident procedure documented conceptually: publish a new pubkey via cross-signed `/.well-known/forge-origin.json` update; legal succession document will include compromise-response instructions. Not yet tested or formally written.

**CEK-20 — Key Recovery**
- Status: **Yes (offline backup)**
- Origin seed backed up offline on the operator's desktop. No cloud-based escrow.

**CEK-21 — Key Inventory**
- Status: **Partial**
- Key locations are documented. No formal inventory system.

---

## DCS — Datacenter Security

Forge NC does not operate any datacenter. All compute is on third-party providers.

**DCS-01 through DCS-15** (off-site equipment, secure area, delivery and removal, asset inventory, protective equipment, environmental threat zones, cabling security, environmental controls, secure disposal, work area, utility disruption, humidity/temperature, access control systems, transit):
- Status: **N/A (provider responsibility)**
- Primary providers: cPanel reseller (web/DB hosting), RunPod (GPU compute). Both are responsible for the physical, environmental, and facility controls covered in the DCS domain.
- RunPod publicly attests SOC 2 Type II coverage.
- cPanel reseller provider's certifications should be requested directly from them by the customer during their own vendor risk assessment.

---

## DSP — Data Security & Privacy

**DSP-01 — Security and Privacy Policy**
- Status: **Partial**
- `TELEMETRY.md` documents the telemetry opt-in policy including redaction rules (no file contents, no prompts, no responses, no IP, no PII) and 90-day retention. No broader formal privacy policy document yet — gap.

**DSP-02 — Secure Disposal**
- Status: **Partial**
- Customer account deletion implemented (`server/account_actions.php:156-204`): revokes tokens, deletes master passport, deletes DB user row. **Does NOT cascade to audit report archives or audit logs tied to the user.** Gap.

**DSP-03 — Data Inventory**
- Status: **Partial**
- Customer data collected: email, org name, endpoint URL, customer API keys (encrypted), system_prompt (encrypted), payment metadata (Stripe-managed, no card storage), machine telemetry (machine_id, pubkey, metrics), audit report metadata, admin audit log entries. Not formally catalogued in a data inventory document.

**DSP-04 — Data Classification**
- Status: **Partial (implicit)**
- Data handled in tiers implicitly: public (Matrix, /report pages), customer-controlled (reports tied to their org), sensitive (customer API keys, system_prompts — encrypted at rest). No formal classification taxonomy.

**DSP-05 — Data Flow Documentation**
- Status: **Partial**
- Data flow evident from code: checkout.php → stripe_webhook.php → audit_orchestrator.php → RunPod worker → (callback) → server → /report + Matrix. No separate data flow diagram.

**DSP-06 — Data Ownership and Stewardship**
- Status: **Yes**
- Customers retain full ownership of their audit data. Offline-verifiable reports mean customers don't need Forge NC to prove audit validity.

**DSP-07 — Data Protection by Design and Default**
- Status: **Partial**
- Sensitive inputs (API keys, system prompts) encrypted at rest. Telemetry opt-in by default (not opt-out). No global privacy-by-design framework, but the principle guides decisions.

**DSP-08 — Data Privacy by Design and Default**
- Status: **Partial**
- PII minimization: telemetry redacts file contents, prompts, responses, IPs before transmission. Audit reports contain customer org name + machine_id + passport_id (signed, not encrypted).

**DSP-09 — Data Protection Impact Assessment (DPIA)**
- Status: **No**
- No formal GDPR Article 35 DPIA performed. Gap if serving EU data subjects at scale.

**DSP-10 — Sensitive Data Transfer**
- Status: **Yes**
- All transfers over HTTPS. Sensitive fields in orchestrator job payloads are decrypted in memory only for the duration of dispatch, transmitted to RunPod over HTTPS, not written to worker disk (`runpod/handler.py:628-634` comment).

**DSP-11 — Personal Data Access, Reversal, Rectification and Deletion**
- Status: **Partial**
- Account deletion: implemented. Account data export: implemented (`server/account_actions.php:60-150`). Rectification: users can edit profile data via dashboard.
- **Gap**: report and audit-log cascading deletion is not automatic — a deleted user's reports remain in the archives for signature integrity. This is documented honestly; customers with strict GDPR erasure requirements should request manual purge.

**DSP-12 — Limitation of Purpose in Personal Data Processing**
- Status: **Yes**
- Data collected is used only for the stated purposes (audit execution, report delivery, telemetry if opted in). No secondary-use data sharing.

**DSP-13 — Personal Data Sub-processing**
- Status: **Partial**
- Sub-processors: Stripe (payments), RunPod (compute), HuggingFace (model weight access for model_weights audits). Not formally listed in a sub-processor addendum yet.

**DSP-14 — Disclosure of Data Sub-processors**
- Status: **Partial (via policy)**
- Disclosed in this document. No subscriber notification mechanism for changes to sub-processor list.

**DSP-15 — Limitation of Production Data Use**
- Status: **Partial**
- Development happens on a separate local instance (forge-nc-dev?) or on the author's workstation with test data. Production data is not routinely used for development.

**DSP-16 — Data Retention and Deletion**
- Status: **Partial**
- Retention documented in `TELEMETRY.md` (raw telemetry 90 days; aggregated profiles indefinite). Audit reports retained indefinitely by current implementation. Per-customer retention SLA not offered yet.

**DSP-17 — Sensitive Data Protection**
- Status: **Yes**
- Customer API keys and system_prompts encrypted at rest (see CEK-03).

**DSP-18 — Disclosure Notification**
- Status: **Partial**
- Responsible disclosure policy at `/security-policy`. No data breach notification template yet.

**DSP-19 — Data Location**
- Status: **Partial**
- Primary web tier in provider's US datacenter. RunPod workers geographically distributed across multiple regions (configurable per job, but not currently user-selectable).

---

## GRC — Governance, Risk & Compliance

**GRC-01 — Governance Program**
- Status: **Partial**
- Single-founder governance. No board, no advisory committee.

**GRC-02 — Risk Management Program**
- Status: **Partial**
- Risk register in `ROADMAP.md:184-196`. No formal ISO 31000 methodology.

**GRC-03 — Organizational Policy Reviews**
- Status: **No**
- No scheduled policy review cycle (because few formal policies exist yet).

**GRC-04 — Policy Exceptions**
- Status: **No**
- No formal policy exception process.

**GRC-05 — Information Security Program**
- Status: **Partial**
- This document; `/security-policy`; `TELEMETRY.md`; cryptographic controls in code.

**GRC-06 — Governance Responsibility Model**
- Status: **Yes (simple)**
- Origin (owner) holds all governance responsibility. One admin is onboarded (per user statement) with scope limited to administrative tasks requiring Origin approval for destructive actions (two-person revocation approval per `memory/forge_external_runner_plan.md`).

**GRC-07 — Information System Regulatory Mapping**
- Status: **Yes** (for product); **Partial** (for operator)
- Product maps to EU AI Act, NIST AI RMF, ISO 42001, SOC 2, HIPAA. Planned: NIST 800-53, CMMC 2.0, FedRAMP.
- Operator compliance mapping via this CAIQ document and roadmap-pending SOC 2 / ISO 42001.

**GRC-08 — Special Interest Groups**
- Status: **Partial**
- Participates indirectly via open-source community (GitHub issues, Discord). No formal CSA, OWASP, or similar membership yet.

---

## HRS — Human Resources

Forge NC is a sole-operator venture with one trusted administrator. HRS controls applicable to larger organizations (background checks, formal training programs, employment contracts) are largely N/A at current scale. Controls are answered honestly rather than aspirationally.

**HRS-01 — Background Screening Policy**
- Status: **N/A (solo + trusted admin)**

**HRS-02 — Acceptable Use of Technology Policy**
- Status: **No formal written policy**
- Operator uses personal workstation; admin's scope is documented in code via role-based access control (`server/auth.php` + `server/admin.php`).

**HRS-03 — Clean Desk Policy**
- Status: **N/A**

**HRS-04 — Remote and Home Working Policy**
- Status: **N/A (solo)**

**HRS-05 — Asset Returns**
- Status: **N/A (no employer-issued assets)**

**HRS-06 — Employment Termination**
- Status: **Partial (documented)**
- Admin role can be revoked by Origin via the auth flag (`server/admin.php`). Origin role cannot be revoked (single-authority model). On founder incapacity, succession is addressed via the Perpetuity Plan's legal succession document (pending).

**HRS-07 — Employment Agreements**
- Status: **No formal NDA/agreement** yet.

**HRS-08 — Personnel Roles and Responsibilities**
- Status: **Yes (implicit)**
- Origin: full authority. Admin: administrative tasks, destructive actions require Origin approval.

**HRS-09 — Non-Disclosure Agreements**
- Status: **No formal written NDA** between Origin and admin currently.

**HRS-10 — Security Awareness Training**
- Status: **No formal training program.**

**HRS-11 — Personal and Sensitive Data Awareness and Training**
- Status: **No formal training.** Cryptographic discipline documented in code/comments.

**HRS-12 — Compliance User Responsibility**
- Status: **Partial**
- Users agree to Terms when creating an account; no extended compliance obligations beyond that.

**HRS-13 — Third-Party Personnel Security**
- Status: **N/A**
- No contracted personnel beyond the single admin.

---

## IAM — Identity & Access Management

**IAM-01 — Identity and Access Management Policy**
- Status: **Yes (implemented in code)**
- `server/auth.php` + `server/admin.php` + `server/includes/auth_guard.php` implement role-based access control. Roles: origin, admin, master, puppet, standalone. Tiers (community, pro, power) are separate from roles.

**IAM-02 — Strong Password Policy**
- Status: **Partial**
- Minimum length: 8 characters (`server/auth.php:173-174`). Storage: bcrypt cost 12 (`server/auth.php:181`). No complexity rules, no forced expiry, no reuse prevention. Gap for strict compliance regimes.

**IAM-03 — Identity Inventory**
- Status: **Yes (technical)**
- All identities tracked in the users table of the database (`server/db.php`). Origin role self-identified; admin role is a boolean flag; master/puppet roles tied to passport tiers.

**IAM-04 — Separation of Duties**
- Status: **Partial**
- Two-person approval for destructive actions (external-runner revocation): admin requests, Origin approves, per `memory/forge_external_runner_plan.md` decision #8. Not yet implemented pending M7.

**IAM-05 — Least Privilege**
- Status: **Yes**
- RBAC enforced at endpoint level. Only Origin can perform Origin-only actions (tier upgrades, admin flag changes, passport revocations, settings changes).

**IAM-06 — User Access Provisioning**
- Status: **Yes (self-service)**
- Users self-provision via signup; paid tier provisioning via Stripe webhook (`server/stripe_webhook.php`).

**IAM-07 — User Access Changes and Revocation**
- Status: **Yes**
- Origin can disable accounts (`server/admin.php:288-297`), revoke tokens (`server/admin.php:240-243`), revoke passports. On deletion: tokens revoked, DB record removed, session destroyed, audit-logged (`server/account_actions.php:165-210`).

**IAM-08 — User Access Review**
- Status: **No formal review cadence yet.**

**IAM-09 — Segregation of Privileged Access Roles**
- Status: **Yes**
- Origin role is hardcoded to owner email; admin flag is separate; master/puppet roles are product-scoped.

**IAM-10 — Management of Privileged Access Roles**
- Status: **Yes**
- Admin flag granted/revoked only by Origin. Audit-logged.

**IAM-11 — CSCM (Credential Management)**
- Status: **Partial**
- Passwords hashed with bcrypt. API tokens stored as SHA-512 hashes (`server/auth.php:234-237`). API keys (customer-provided) encrypted via sodium_secretbox.

**IAM-12 — Secrets Management**
- Status: **Partial**
- Secrets in `server/data/audit_config.json` (api_endpoint_secret, orchestrator_secret), `server/data/origin_key.json` (root key). GitHub Actions uses repo secrets for FORGE_API_SECRET during weights-build template update.

**IAM-13 — User Access Restrictions / Time of Use**
- Status: **Partial**
- Session lifetime: 7 days cookie with regeneration on login (`server/auth.php:30`). Tokens are persistent until revoked. No time-of-day access restrictions.

**IAM-14 — Third Party Identity Management**
- Status: **Partial**
- Discord OAuth implemented for account linking only (not as primary auth) via `server/discord_oauth.php`. Not a full SSO integration.

**IAM-15 — Strong Authentication**
- Status: **No (MFA)**
- MFA not implemented. Authentication is password + session cookie, or X-Forge-Token header (bearer). Gap for enterprise compliance; planned for future.

**IAM-16 — Passwords Management**
- Status: **Partial**
- Users can change password via `server/account.php:58-60` (requires old-password re-verification). No password history check, no mandatory rotation.

---

## IPY — Interoperability & Portability

**IPY-01 — Interoperability and Portability Policy**
- Status: **Yes** (designed-in)
- Forge audit reports are signed JSON artifacts verifiable offline using only the Origin public key and any Ed25519 library. Customers are never locked in.

**IPY-02 — Application Interface Availability**
- Status: **Yes**
- OpenAI-compatible API interface used in `forge/models/openai_backend.py`. Reports are consumable by any tool that reads JSON.

**IPY-03 — Secure Interoperability and Portability Management**
- Status: **Yes**
- Ed25519 signatures are portable; verification does not require contacting Forge NC's servers.

**IPY-04 — Data Portability Contractual Obligations**
- Status: **Yes**
- Per `server/account_actions.php:60-150`, customers can export account data. Certified audit reports are delivered as downloadable signed JSON + PDF.

---

## IVS — Infrastructure & Virtualization Security

**IVS-01 — Infrastructure and Virtualization Security Policy**
- Status: **Partial (provider-dependent)**
- Hosting infrastructure is managed by the cPanel reseller and RunPod. Application-level infrastructure (container images, API subdomain, Cloudflare rules) is operator-managed.

**IVS-02 — Capacity and Resource Planning**
- Status: **Partial**
- RunPod auto-scales to serverless capacity; `audit_orchestrator.php` selects GPU tier based on model size (`forge/model_compat.py` helpers). Web tier has provider-dependent capacity limits.

**IVS-03 — Network Security**
- Status: **Yes**
- Cloudflare WAF fronts forge-nc.dev (TLS 1.2+, HSTS, strict CSP in `server/.htaccess:104-112`).
- api.forge-nc.dev DNS-only bypass requires X-Forge-API-Secret header verified via `hash_equals()` (`server/audit_orchestrator.php:29-40`).
- Webhook authentication: RunPod callbacks verified by embedded webhook_secret (constant-time compared in `server/audit_orchestrator.php:728-732`).

**IVS-04 — OS Hardening and Base Controls**
- Status: **Partial (provider-dependent)**
- Web/DB hosting OS hardening is the cPanel reseller's responsibility. Docker images for RunPod workers use minimal base images (python:3.11-slim for API, runpod/pytorch pre-cached for weights). No non-root USER directive in Dockerfiles (acceptable for ephemeral containers).

**IVS-05 — Production and Non-Production Environments**
- Status: **Partial**
- Production: forge-nc.dev. No formal staging/QA environment; the operator develops locally and deploys directly to production. Gap for mature SDLC.

**IVS-06 — Segmentation and Segregation**
- Status: **Partial**
- forge-nc.dev (public) vs api.forge-nc.dev (API bypass) separation. RunPod workers are ephemeral, single-use, destroyed after job completion (`runpod/handler.py` lifecycle).

**IVS-07 — Migration to Cloud Environments**
- Status: **N/A**
- Forge was designed cloud-first; no legacy migration.

**IVS-08 — Network Architecture Documentation**
- Status: **Partial**
- Documented in this CAIQ and in `memory/forge_external_runner_plan.md`. No separate architecture diagram.

**IVS-09 — Network Defense**
- Status: **Yes (provider)**
- Cloudflare WAF + DDoS mitigation. Per-endpoint rate limiting at auth layer (`server/db.php:249-266`: 20 requests / 300s / IP).

---

## LOG — Logging & Monitoring

**LOG-01 — Logging and Monitoring Policy**
- Status: **Partial (informal)**

**LOG-02 — Audit Logs Protection**
- Status: **Partial**
- Admin audit logs stored in database with actor, action, target, timestamp, IP hash. No HMAC-chain or signed logs. Standard file/DB permissions apply.

**LOG-03 — Security Monitoring and Alerting**
- Status: **Partial**
- `server/alert.php` supports Discord/Slack/email alerts for fleet health anomalies; disabled by default.

**LOG-04 — Audit Logs Access and Accountability**
- Status: **Yes**
- Origin-only access to admin audit logs via `server/admin.php`.

**LOG-05 — Audit Logs Monitoring and Response**
- Status: **Partial**
- No automated SIEM monitoring. Logs reviewed manually as needed.

**LOG-06 — Clock Synchronization**
- Status: **Yes (provider)**
- Hosting server clock synced via NTP (provider's responsibility). RunPod workers sync via their infrastructure.

**LOG-07 — Logging Scope**
- Status: **Yes**
- Admin actions, auth failures, webhook events, customer deposits/dispatches, audit queue state transitions — all logged. Per-order execution logs at `server/data/audit_logs/{order_id}.log` via RemoteLogHandler in `runpod/handler.py`.

**LOG-08 — Log Records**
- Status: **Yes**
- Minimum fields: timestamp, actor (email/role), action, target, details, IP hash.

**LOG-09 — Log Protection**
- Status: **Partial**
- File permissions + database access control. Not cryptographically protected against tampering.

**LOG-10 — Encryption Monitoring and Reporting**
- Status: **No**
- No monitoring of crypto algorithm usage beyond code review.

**LOG-11 — Transaction / Activity Logging**
- Status: **Yes**
- Full transaction log in the audit orchestrator (`server/audit_orchestrator.php` write paths + `server/db.php:137-157` admin audit log).

**LOG-12 — Access Control Logs**
- Status: **Yes**
- Login successes and failures logged (`server/auth.php:116, 144`).

**LOG-13 — Failures and Anomalies Reporting**
- Status: **Partial**
- Fraud reports logged to `server/data/fraud_reports.jsonl` via `server/verify_report.php:270-284`. Alert system can notify on anomalies.

---

## SEF — Security Incident Management, E-Discovery, Cloud Forensics

**SEF-01 — Security Incident Management Policy**
- Status: **Partial**
- Responsible disclosure policy at `/security-policy`. No formal IR plan beyond that.

**SEF-02 — Service Management Policy and Procedures**
- Status: **Partial**
- Operator acts as tier-1 through tier-3 support. Customer email support via account contact.

**SEF-03 — Incident Response Plans**
- Status: **No**
- Not formally written.

**SEF-04 — Incident Response Testing**
- Status: **No**

**SEF-05 — Incident Response Metrics**
- Status: **No**

**SEF-06 — Event Triage Processes**
- Status: **Partial (informal)**

**SEF-07 — Security Breach Notification**
- Status: **Partial**
- `/security-policy` commits to notifying affected parties. Process for regulatory notification (GDPR Article 33/34, US state laws) not formally documented.

**SEF-08 — Points of Contact Maintenance**
- Status: **Yes**
- `security@forge-nc.dev` in `/.well-known/security.txt` and `/security-policy`.

---

## STA — Supply Chain Management, Transparency & Accountability

**STA-01 — SSRM (Shared Security Responsibility Model) Policy**
- Status: **Yes**
- This document's Shared Responsibility Model section serves as the SSRM.

**STA-02 — SSRM Supply Chain**
- Status: **Partial**
- Upstream dependencies listed in `pyproject.toml` + `server/composer.json` (if present). Container base images pinned in Dockerfiles.

**STA-03 — SSRM Guidance**
- Status: **Partial**
- Shared-responsibility implications noted in this document's provider table.

**STA-04 — SSRM Control Ownership**
- Status: **Yes**
- Table in "Shared Responsibility Model" section above.

**STA-05 — SSRM Documentation Review**
- Status: **Partial**
- This CAIQ is the review artifact. Cadence for re-review: annually or upon major architectural change.

**STA-06 — SSRM Control Implementation**
- Status: **Partial**
- Controls implemented per this document; specific control implementations by third parties available from the respective provider's compliance artifacts.

**STA-07 — Supply Chain Inventory**
- Status: **Partial**
- Direct dependencies listed in pyproject.toml and composer.json. No formal SBOM (CycloneDX/SPDX) published yet.

**STA-08 — Supply Chain Risk Management**
- Status: **Partial**
- Critical vendors reviewed during selection (RunPod SOC 2, Cloudflare ISO/SOC/PCI). No formal ongoing vendor risk management process.

**STA-09 — Primary Service and Contractual Agreement**
- Status: **Partial**
- Provider Terms of Service govern Forge NC's use of upstream services. No custom contractual agreements yet.

**STA-10 — Supply Chain Agreement Review**
- Status: **No formal cadence.**

**STA-11 — Internal Compliance Testing**
- Status: **Partial**
- This CAIQ is the internal compliance artifact.

**STA-12 — Supply Chain Service Agreement Compliance**
- Status: **Partial**

**STA-13 — SSRM Implementation**
- Status: **Partial**

**STA-14 — Supply Chain Data Security Assessment**
- Status: **Partial**
- Model weights downloaded from HuggingFace via `runpod/handler.py:1563-1568` using `snapshot_download()`. Relies on HuggingFace-side integrity plus HTTPS. Explicit hash allowlisting is a planned enhancement.

---

## TVM — Threat & Vulnerability Management

**TVM-01 — Threat and Vulnerability Management Policy**
- Status: **Partial**

**TVM-02 — Malware Protection Policy**
- Status: **Partial (provider-dependent)**
- Operator uses personal Windows workstation with Defender. No enterprise endpoint protection mandate.

**TVM-03 — Vulnerability Remediation Schedule**
- Status: **Partial**
- Informal: security fixes prioritized; other fixes as resources allow. No formal SLA.

**TVM-04 — Detection Updates**
- Status: **Partial**
- `forge/threat_intel.py` supports upgradeable threat signatures for the Crucible protocol (bundled + fetched + user custom), with strict cryptographic envelope verification. This is product-level, not operator-level.

**TVM-05 — External Library Vulnerabilities**
- Status: **Partial**
- Dependencies reviewed at install time. No automated Dependabot / Snyk scanning in CI yet. Gap.

**TVM-06 — Penetration Testing**
- Status: **No**
- No formal pentest performed. Planned for later phase.

**TVM-07 — Vulnerability Identification**
- Status: **Partial**
- Manual code review + pytest. No automated scanners.

**TVM-08 — Vulnerability Prioritization**
- Status: **Partial**
- CVSS-like severity assigned informally by operator.

**TVM-09 — Vulnerability Management Reporting**
- Status: **No**
- No formal reporting.

**TVM-10 — Vulnerability Management Metrics**
- Status: **No**

---

## UEM — Universal Endpoint Management

Forge NC has no endpoint fleet. Operator and admin work from personal devices without enterprise device management.

**UEM-01 through UEM-14**:
- Status: **N/A (solo operation)** for most controls.
- Customer-deployed external runners are **customer responsibility** — they deploy the Docker container inside their own VPC with their own endpoint controls, network policies, and runtime protections. Forge NC provides the signed, auditable container; customers provide the environment.

---

## Acknowledgement

This response was prepared with direct reference to the Forge NC codebase, public roadmap, and architecture documentation. It represents the state of controls as of the response date. Updated versions will be published at the canonical URL above. Questions regarding specific controls may be directed to security@forge-nc.dev.

---

*End of CAIQ v4 response.*