Skip to content

Finnest IRAP Deployment Architecture

Date: 2026-04-16 Status: Draft Classification target: OFFICIAL:Sensitive (architected for PROTECTED) Scope: Full detail of the IRAP deployment variant — infrastructure, boundary proxy, operational controls, and the 16 IR-* guardrails.

Related documents: architecture.md (main), ../brainstorms/brainstorm-06-irap-strategy.md, ../10-GUARDRAILS.md §12 (IR-01–IR-16), ../adrs/adr-0010-australian-data-residency-ai-providers.md.

Scope & Non-Goals

In scope:

  • Architecture of the IRAP deployment variant
  • Three-layer model (AWS infra / Go boundary proxy / Elixir app)
  • Differences from commercial deployment (what runs, what's disabled, what's stricter)
  • Assessment strategy and timeline
  • Operational controls (access, monitoring, change management)

Out of scope:

  • IRAP assessor selection (commercial concern)
  • System Security Plan (SSP) content — separate document, produced during Phase 3 IRAP prep
  • Specific penetration-test findings — operational artefacts

Strategy: Three-Layer Approach

┌─────────────────────────────────────────────────────────────────┐
│ LAYER 1: INFRASTRUCTURE (AWS ap-southeast-2, IRAP-assessed)      │
│                                                                  │
│ Dedicated VPC (no peering to commercial)                         │
│ Multi-AZ RDS (encrypted; CloudHSM keys)                          │
│ S3 (Object Lock compliance mode; SSE-KMS; CloudHSM)              │
│ CloudHSM (FIPS 140-2 Level 3)                                    │
│ CloudWatch Logs (7-year retention)                               │
│ CloudTrail (API audit)                                           │
│ GuardDuty (threat detection)                                     │
│ Security Hub (compliance dashboard)                              │
│ WAF (ALB-level request filtering)                                │
│ No internet egress except explicitly allowlisted endpoints       │
└────────────────────────────────┬────────────────────────────────┘
                                 │
┌────────────────────────────────▼────────────────────────────────┐
│ LAYER 2: SECURITY BOUNDARY (Go proxy, ~500 LOC, ISM-listed)      │
│                                                                  │
│ - TLS 1.2+ termination with FIPS-compliant cipher suites         │
│ - Request validation (content type, size, injection patterns)    │
│ - Authentication verification (JWT + MFA + FIDO2)                │
│ - Classification header injection (OFFICIAL:Sensitive)           │
│ - Full request/response audit logging                            │
│ - Rate limiting / DDoS protection                                │
│ - W3C traceparent propagation (OpenTelemetry continuity)         │
│ - Response filtering (strip internal headers, debug info)        │
│ - NO business logic                                               │
│ - NO database access                                              │
│ - NO state                                                        │
└────────────────────────────────┬────────────────────────────────┘
                                 │
┌────────────────────────────────▼────────────────────────────────┐
│ LAYER 3: APPLICATION (Finnest Elixir — same codebase as commercial)│
│                                                                  │
│ config/runtime.exs branches on :irap environment:                │
│   - Bedrock Sydney only (no direct Anthropic API)                │
│   - 15-min sessions, 10-min idle lock                            │
│   - FIDO2 mandatory                                              │
│   - IP allowlist                                                 │
│   - Integrations disabled: SEEK, Indeed, LinkedIn, Calendly,     │
│     WhatsApp, Google OAuth, Apple OAuth                          │
│   - Enhanced audit level (field-level changes)                   │
│   - Microsoft Entra ID only for SSO                              │
│                                                                  │
│ AI provider: AWS Bedrock ap-southeast-2                          │
│ Email: AWS SES Sydney                                            │
│ SMS: SMSGlobal (Australian-based)                                │
│ Voice: disabled                                                  │
│ Payroll: KeyPay (Australian-hosted)                              │
│ Secrets: AWS SSM Parameter Store with CloudHSM                   │
│ Errors: Sentry self-hosted in IRAP VPC                           │
│ On-call: Opsgenie (Australian billing)                           │
└─────────────────────────────────────────────────────────────────┘

Why three layers:

  • Layer 1 is already IRAP-assessed by AWS. No re-assessment needed.
  • Layer 2 is small (~500 LOC of Go), written in an ISM-listed language. Scrutiny focuses here. This is the strategic choice: the assessor audits 500 lines of Go + operational controls, not 150K+ LOC of Elixir.
  • Layer 3 inherits the assessed boundary. The Elixir application's language status becomes less critical because the security boundary is Go.

One Codebase, Dual Deployment

Config branching

# config/runtime.exs

import Config

case System.get_env("FINNEST_ENV") || "commercial" do
  "commercial" ->
    import_config "commercial.exs"

  "irap" ->
    import_config "irap.exs"

  other ->
    raise "Unknown FINNEST_ENV: #{other}. Expected :commercial or :irap."
end

config/irap.exs enforces IRAP constraints

import Config

config :finnest, :ai_provider, FinnestAgents.AiProvider.BedrockSydney

config :finnest, :session,
  timeout_seconds: 900,          # 15 min — IR-07
  idle_lock_seconds: 600,        # 10 min — IR-07
  remember_me_enabled: false     # IR-06

config :finnest, :mfa,
  required: true,                # IR-06
  allowed_methods: [:fido2]      # FIDO2 only — no TOTP, no SMS (phishable)

config :finnest, :data_region, "ap-southeast-2"  # IR-02

config :finnest, :network,
  ip_allowlist_enabled: true     # IR-08

config :finnest, :disabled_integrations, [       # IR-13
  :seek_api,
  :indeed_api,
  :linkedin_api,
  :calendly,
  :whatsapp,
  :google_oauth,
  :apple_oauth
]

config :finnest, :secrets,
  adapter: FinnestCore.Secrets.Adapters.SsmParameterStore,
  kms_key: System.fetch_env!("CLOUDHSM_KEY_ARN")

config :finnest, :sentry,
  adapter: FinnestCore.Telemetry.Sentry.SelfHosted,
  endpoint: System.fetch_env!("SENTRY_IRAP_ENDPOINT")

config :finnest, :oncall,
  adapter: FinnestCore.Oncall.Opsgenie

config :finnest, :audit_level, :enhanced  # field-level change capture

config :finnest, Finnest.Repo,
  ssl: true,
  ssl_opts: [verify: :verify_peer, cacerts: :public_key.cacerts_get()],
  parameters: [application_name: "finnest_irap"]

No code fork

Single git branch. Same image. The difference between commercial and IRAP is the FINNEST_ENV environment variable and the deployed infrastructure. This is AR-19: "IRAP deployment is a config variant, not a code fork."

Feature Matrix (Commercial vs IRAP)

Feature Commercial IRAP
AI Provider Anthropic Direct AWS Bedrock ap-southeast-2
Session Timeout 60 min 15 min (IR-07)
Idle Lock — 10 min (IR-07)
Remember me Optional Disabled
MFA Optional TOTP; mandatory FIDO2 for admin/payroll/director Mandatory FIDO2 (IR-06)
SSO Google / Microsoft / Apple OAuth Microsoft Entra ID only (IR-13)
Audit Level Standard Enhanced (field-level change capture)
Email AWS SES AWS SES Sydney
Job Boards SEEK, Indeed, LinkedIn, Jora Disabled (IR-13 — offshore data flow)
Scheduling Google Calendar / Outlook Outlook only via Microsoft Entra
Calendly Enabled Disabled (US-hosted)
WhatsApp Enabled Disabled
IP Allowlist None Client network ranges (IR-08)
Key Management AWS KMS AWS CloudHSM (FIPS 140-2 Level 3) (IR-09)
Secrets Bitwarden Secrets Manager AWS SSM Parameter Store + CloudHSM
Data Classification Headers None OFFICIAL:Sensitive injected by Go proxy
Webhooks All providers Australian endpoints only
Sentry SaaS Self-hosted in IRAP VPC
Dashboards Grafana SaaS or self-hosted Self-hosted in IRAP VPC
On-call PagerDuty Opsgenie (AU billing)
Mobile build Public App Store + Play Store Microsoft Intune distribution only (IR-16); separate Flutter flavor
Mobile Analytics Firebase Analytics Disabled (IR-15)
Deployment approval 1 reviewer 2-person approval (IR-12)
CI pipeline GitHub Actions standard + Semgrep SAST + ZAP DAST + Sigstore-signed SBOM (IR-14)
Penetration testing Annual Quarterly (IR-14)
Session recording N/A All SSM admin sessions recorded (IR-11)
Developer access Standard SSH / IAM Zero standing access; JIT via SSM (IR-11)

Infrastructure Layer (AWS ap-southeast-2)

VPC Topology

ap-southeast-2 — Dedicated IRAP VPC (10.10.0.0/16)
│
├── Public Subnets (10.10.1.0/24, 10.10.2.0/24 — 2 AZs)
│   ├── ALB (TLS 1.3 termination; WAF attached)
│   └── NAT Gateway (per AZ)
│
├── Private App Subnets (10.10.10.0/24, 10.10.11.0/24 — 2 AZs)
│   ├── ECS Fargate: Go Boundary Proxy (2 tasks, one per AZ)
│   ├── ECS Fargate: Finnest Elixir app (2+ tasks)
│   ├── ECS Fargate: Sentry (self-hosted)
│   ├── ECS Fargate: Grafana (self-hosted)
│   └── AWS Secrets Manager VPC Endpoint
│
├── Private Data Subnets (10.10.20.0/24, 10.10.21.0/24 — 2 AZs)
│   ├── RDS PostgreSQL (Multi-AZ; encrypted; CloudHSM keys)
│   ├── S3 VPC Gateway Endpoint (access S3 without internet)
│   └── CloudHSM Cluster (FIPS 140-2 Level 3)
│
└── Monitoring
    ├── CloudWatch Logs (7-year retention — IR-10)
    ├── CloudTrail (all API calls — IR-10)
    ├── GuardDuty (threat detection)
    ├── Security Hub (compliance dashboard)
    └── VPC Flow Logs → CloudWatch

Non-negotiables:

  • No VPC peering to the commercial VPC (IR-04)
  • No internet egress except via allowlist (outbound to Bedrock, KeyPay, SMSGlobal, VEVO, ATO STP endpoints — AU region addresses only)
  • No cross-region data flow except documented DR snapshots to ap-southeast-4 (Melbourne)
  • CloudHSM is the root of trust — RDS encryption keys, Cloak column keys, secret manager keys all derive from CloudHSM

Storage

RDS PostgreSQL:

  • Multi-AZ with automatic failover
  • Encryption at rest via CloudHSM-backed KMS key
  • TLS required for all connections (SE-15)
  • 7-year automated backup retention
  • Point-in-time recovery via continuous WAL archiving (supports 15-min RPO per D16)
  • Cross-region snapshot to ap-southeast-4 for DR

S3:

  • Object Lock in compliance mode — deleted objects are genuinely unrecoverable even with root credentials (required for 7-year retention guarantees on documents)
  • SSE-KMS encryption with CloudHSM keys
  • No public access
  • VPC Gateway Endpoint only — no internet path

Secrets:

  • AWS SSM Parameter Store for env-injected secrets
  • CloudHSM-backed KMS keys protecting the parameters
  • SSM Parameter rotation quarterly
  • FinnestCore.Secrets.Adapters.SsmParameterStore is the only way the app reads secrets

Security Boundary (Go Proxy)

Why Go, why a proxy

Why Go: ISM-listed memory-safe language. Present at the security boundary satisfies the assessor regardless of the application language behind it. B01 / B06 analysis concluded this is the most efficient path to IRAP certification for a platform that wants to use Elixir.

Why a proxy (not a library inside Phoenix): Separation of duties. The proxy has zero business logic, zero database access, zero state. Its code can be audited exhaustively in isolation. A vulnerability in Phoenix domain code cannot bypass the proxy.

Responsibilities (ordered by request flow)

  1. TLS 1.2+ termination with FIPS-compliant cipher suites (TLS 1.3 preferred; 1.2 for legacy client compatibility)
  2. Request validation
  3. Content-Type allow list
  4. Content-Length ≤ configured max (prevent payload-based DoS)
  5. Injection pattern scanning (SQL, command, NoSQL) — coarse layer; Elixir has fine layer
  6. Authentication verification
  7. JWT signature check against public key (rotated quarterly)
  8. Expiration + not-before validation
  9. MFA claim presence check
  10. Classification header injection — proxy adds X-Classification: OFFICIAL:SENSITIVE to every request; app logs the classification into every event
  11. Request/response audit logging — full request (headers + body hash) and response (status + body hash) to CloudWatch; no PII in log messages, only IDs and hashes
  12. Rate limiting — per-JWT-sub bucket (additional to Phoenix Hammer)
  13. W3C traceparent propagation — propagates incoming trace header or creates one; passes to Phoenix via standard HTTP header (Part 7 decision: end-to-end trace continuity across proxy)
  14. Response filtering
  15. Strip internal headers (X-Internal-*, server info, stack traces)
  16. Strip debug body content if accidentally present
  17. DDoS protection
  18. Coarse rate limit at ALB level (AWS WAF)
  19. Fine rate limit in proxy
  20. Circuit breaker: if error rate >5% sustained, drop to 503 for 30s

What the proxy does NOT do

  • No business logic
  • No database access
  • No authentication primary (delegates to Phoenix for password + FIDO2; proxy only verifies the resulting JWT)
  • No state between requests (stateless)
  • No translation between protocols (it's an HTTP proxy, not a protocol gateway)

Deployment

  • ECS Fargate, 2 tasks minimum (Multi-AZ)
  • Container image: distroless base + Go binary (≤20 MB total)
  • No shell, no package manager in container
  • Health check: /healthz returns 200 if proxy can reach Phoenix /ready endpoint

Code size discipline

The proxy is ~500 LOC by design. If it grows past 1000 LOC, it's either doing too much or poorly factored. Every added capability is reviewed against "can Phoenix do this instead?"

Application Layer (Finnest Elixir on IRAP)

What's different from commercial

Same codebase, different runtime behaviour driven by config/irap.exs:

  • AiProvider set to BedrockSydney
  • FileStorage set to S3ObjectLock
  • Secrets set to SsmParameterStore
  • CommVoice adapter set to Disabled (voice isn't offered in IRAP)
  • JobBoard adapter set to Disabled
  • Calendar adapter set to MicrosoftEntraOnly
  • Session plug config: 15-min timeout, 10-min idle
  • MFA plug config: :fido2_required
  • Audit logger config: :enhanced (captures field-level changes on every update)
  • Phoenix endpoint config: IP allowlist middleware enabled

Application-level controls

IP allowlist (IR-08):

  • FinnestWeb.Plugs.IpAllowlist reads client network ranges from public.organisations.settings.ip_allowlist
  • Requests from outside the allowlist → 403 before authentication check
  • Allowlist updates are admin-only, require 2-person approval, logged to audit

Enhanced audit (IR-10):

  • Standard audit logs create/update/delete events
  • Enhanced audit captures old-value/new-value pairs for every changed field on updates
  • Writes to event store (same immutable hash-chained table — no separate audit store needed)
  • 7-year retention via partition pruning policy

FIDO2 mandatory (IR-06):

  • First-time user enrollment forced at first login
  • No TOTP option displayed in IRAP UI
  • No SMS-based backup codes (phishable)
  • Backup codes generated as download-once printable recovery codes

Access Control (IRAP Production)

Zero standing access (IR-11)

Nobody has "always logged in" to IRAP production. Access is granted per-task via AWS SSM Session Manager:

Developer needs to investigate incident
  └─ Requests access via ticketing system
      └─ Cleared approver reviews (must be a different cleared person)
          └─ Approved: IAM role assumed for 1 hour max
              └─ SSM Session Manager creates session
                  └─ All commands recorded (session manager recording)
                  └─ CloudTrail logs the IAM role usage
              └─ Role auto-revokes at expiry

No SSH. No bastion host. No VPN-to-private-subnet. SSM is the only production access path.

Break-glass procedure

For genuine emergencies (all approvers unavailable; production down):

  1. Break-glass IAM user exists but MFA device is held in physical safe by a non-cleared third party (e.g. company secretary)
  2. Invoking break-glass requires physical device retrieval + written justification
  3. Every break-glass use triggers incident review within 48 hours
  4. Tested annually during DR drill

IAM principle

Every IAM role has the minimum policy for its purpose. Specifically:

  • Application runtime role: read SSM Parameter Store values; read/write specific S3 prefix; read/write specific RDS database — nothing else
  • Admin role: granted per-task via SSM; time-limited
  • Deployment role: used by CI; can push to ECR, update ECS service — cannot read application data
  • Monitoring role: read CloudWatch Logs; read CloudTrail — no write

CI/CD Pipeline Separation

Stage Commercial IRAP
Source main branch Same branch
Build GitHub Actions GitHub Actions (separate workflow ci-irap.yml)
Security scan — dependency mix deps.audit + trivy + grype (CVE DB)
Security scan — static Sobelow + Semgrep (additional rule sets)
Security scan — dynamic — ZAP against IRAP-staging
SBOM CycloneDX generation + Sigstore signing
Review gate 1 human review 1 human + security reviewer
Container signing — Cosign-signed container images
Staging deploy Auto on merge to main Manual promotion
Bake period — 1–2 weeks in staging
Production deploy 1-person promote 2-person approval (IR-12)
Penetration test Annual (3rd party) Quarterly (3rd party)

Two-person approval mechanism

Implemented via GitHub environment protection rules:

  • irap-production GitHub Environment requires 2 reviewers
  • Reviewers are a defined list of cleared team members
  • Both approvals required; cannot self-approve
  • Deployment job is blocked until both approvals land
  • Approvals are logged as CI artefacts for audit trail

Assessment Strategy

Phase 0: Pre-assessment (Weeks 1–2 of 44-week roadmap)

  • One-day engagement with a selected IRAP assessor
  • Goals:
  • Validate three-layer architecture as acceptable
  • Confirm Elixir acceptance given Go boundary proxy
  • Agree on assessment boundary (Go proxy + AWS infra + operational controls; Elixir in scope but not primary focus)
  • Identify any preliminary gaps in the approach
  • Artefacts needed: architecture.md, this irap.md, draft SSP outline
  • Budget: $25K (B06)
  • Decision gate: If assessor rejects approach, need to pivot (likely to Go/Rust application layer behind proxy)

Phase 0–2: Parallel IRAP groundwork (Weeks 1–20)

  • Build Go boundary proxy (2 weeks of development)
  • Provision IRAP VPC via Terraform (Weeks 3–4)
  • Implement SAST/DAST pipeline (Week 5)
  • Draft SSP, Statement of Applicability (SoA), Security Risk Management Plan (SRMP)

Phase 3: IRAP-ready build (Weeks 21–32)

  • Complete IRAP infrastructure (CloudHSM, S3 Object Lock, separate RDS)
  • Write runbooks (8 scenarios from main arch Part 10)
  • Internal penetration test
  • Remediate findings
  • Staging environment fully operational

Phase 4: Formal assessment (Weeks 33–44)

  • Stage 1: Documentation review by assessor (~2 weeks)
  • Stage 2: Technical testing (~4 weeks)
  • Remediation window (~2 weeks) for any findings
  • Certification: OFFICIAL:Sensitive

Ongoing

  • Quarterly: Penetration test
  • Annually: Reassessment
  • On-change: Security impact assessment for any major architectural change

Monitoring, Logging, Alerting (IRAP)

Observability stack (IRAP VPC)

All observability services run inside the IRAP VPC. Any service that sees PII or classified metadata stays in-region.

Concern Service Deployment
Traces OpenTelemetry → Tempo Self-hosted in IRAP VPC
Metrics Prometheus → Grafana Self-hosted in IRAP VPC
Logs CloudWatch Logs → Grafana Loki CloudWatch (native in-region) + Loki self-hosted for aggregation
Errors Sentry Self-hosted in IRAP VPC (Part 10 decision)
Synthetic Internal heartbeats via scheduled Lambda-equivalent (ECS task) In-region
Alerts Opsgenie AU Atlassian billing

Audit log integrity

  • All audit events captured by Phoenix go to events.domain_events (hash-chained)
  • All AWS API calls captured by CloudTrail
  • All Go proxy requests captured by CloudWatch Logs
  • Monthly: hash-chain integrity verification script runs; output signed and archived

What gets logged (structured, PII-free)

  • Every authenticated request: user_id (UUID), org_id (UUID), route, status, duration_ms, correlation_id, classification
  • Every database write: aggregate_id, event_type, correlation_id, before-hash, after-hash
  • Every agent action: session_id, tool_name, correlation_id, duration_ms, cost_aud
  • Every AI call: model, tokens, cache_stats, cost_aud, prompt_hash and response_hash, never plaintext

What does NOT get logged

  • User message content (stored in agents.messages under audit retention, never in logs)
  • Document content (stored in S3 with Object Lock, never in logs)
  • PII values (names, TFNs, addresses) — logged by ID only (Commandment #24)

Alerting

Same four golden signals as commercial, plus IRAP-specific:

  • Failed auth attempts >10/min per user → lockout + alert
  • IP allowlist rejection >50/hour → suspected scan → alert
  • FIDO2 enrollment failures >5% → alert (potentially legitimate UX issue)
  • SSM admin session opened → audit alert (not paging, but logged + reviewed weekly)
  • CloudHSM key usage anomalies (via CloudWatch metric) → alert
  • Break-glass IAM use → immediate page + mandatory incident review

Mobile for IRAP

See mobile.md for the full mobile architecture. IRAP-specific deltas:

  • Separate Flutter flavor (flutter build apk --flavor irap) produces a distinct APK/IPA
  • Distributed via Microsoft Intune (MDM) only (IR-16) — not public App Store
  • No Firebase Analytics (IR-15); FCM Push OK but only for encrypted payload notifications with no PII
  • Cert pinning to IRAP-specific ALB cert
  • Biometric + PIN required for app entry
  • 5-min idle lock (stricter than commercial 60-min)
  • Remote wipe via Intune
  • No SMS backup codes for MFA — FIDO2 or printable recovery only

Risks & Mitigations

Risk Mitigation
IRAP assessor rejects Elixir even with Go proxy Phase 0 pre-assessment validates before committing. Fallback: application layer rewrites to Go domain by domain via MCP contracts. Cost: ~3 months of work per extracted domain. Mitigated to acceptable.
PII sent to US API (misconfiguration) AiProvider port constrained to ap-southeast-2; VPC network ACLs block outbound to US IPs; quarterly egress audit
Shared database with commercial Separate RDS instance; separate VPC; no peering (IR-03, IR-04); infrastructure-as-code prevents misconfiguration
Offshore log shipping CloudWatch ap-southeast-2 only; Sentry self-hosted in VPC; Grafana in VPC
Supply chain attack (compromised dependency) Locked mix.lock; Renovate soak period; SBOM generation; Sigstore signing; harden-runner on CI
Missing audit trail Event store append-only, trigger-enforced, hash-chained (AR-17, SE-21)
Excessive session timeout 15-min enforced by Phoenix session plug; config fails fast if wrong
No change management Separate CI/CD with 2-person approval; security review gate; 1–2 week bake period
Developer SSH to production Zero standing access; SSM JIT only; no SSH keys in IAM roles; no bastion host
Rogue agent cost explosion BudgetGuard circuit breaker (AI-08)
Cross-tenant agent state leak Per-session process termination; org_id injected by infrastructure (AI-03, AI-04)
Whole-region AWS outage in ap-southeast-2 Cross-region snapshot to ap-southeast-4 (Melbourne); documented DR runbook; expect 1–2 week recertification gap (acceptable per defence contract realities)
CloudHSM cluster failure CloudHSM cluster has multiple HSMs; 14-day backup retention; automated failover
Break-glass credential compromise MFA device held physically off-site; use requires physical retrieval + written justification + 48-hr incident review

Cost Model

One-time (to certification)

Item Estimate Notes
Pre-assessment $25K Phase 0
Go proxy development Included in phase 3 engineering ~2 weeks of dev time
IRAP VPC provisioning ~$5K infra setup Terraform-driven
Security documentation (SSP, SoA, SRMP) $20K Technical writing + security engineer
SAST/DAST tooling licensing $15K/year Semgrep, ZAP enterprise
Penetration test (pre-assessment) $40K 3rd party
Formal assessment $200K Stage 1 + Stage 2 + remediation
Total to certification ~$305K Over 12 months (B06 $330K)

Ongoing annual

Item Annual
IRAP infrastructure (dedicated VPC, RDS, CloudHSM, monitoring) $80K
Quarterly penetration testing $30K
Security tooling (SAST, DAST, SBOM) $30K
Annual reassessment $120K
Compliance FTE (partial allocation) $150K
Documentation updates $10K
Total ongoing ~$420K/year

Revenue justification (B06)

Defence Clients Employees Revenue (@$15 PEPM) Covers IRAP ongoing?
1 500 $90K No
3 1,500 $270K Partial
5 2,500 $450K Break-even
10 5,000 $900K 2×

Plus: AgenticAI credits at premium rates, government tender eligibility, 3–5 year contract stickiness.

Pre-Requisite Actions (Phase 0)

  1. Engage IRAP assessor for pre-assessment (Week 1–2). Budget $25K.
  2. Build Go boundary proxy (~2 weeks development). Validate against Phase 0 Finnest Elixir scaffold.
  3. Set up IRAP VPC on AWS Sydney (Terraform). Separate account preferred.
  4. Write System Security Plan (SSP) — define assessment boundary, data classification scheme, controls mapping.
  5. Implement SAST/DAST in CI pipeline — Semgrep + ZAP integrated with GitHub Actions.
  6. Document data flows — every data category, source, destination, retention. Required for SoA.

Open Questions & Decisions Pending

# Item Phase Owner
IR-OI-01 IRAP assessor selection (CyberCX, Content Security, Paraflare, others) 0 Gautham + legal
IR-OI-02 Target certification level confirmation: OFFICIAL:Sensitive certain; PROTECTED aspirational 0 Commercial/Sales
IR-OI-03 Cross-region DR target: ap-southeast-4 (Melbourne) confirmation 1 Infra lead
IR-OI-04 Mobile Intune tenant provisioning strategy (per-client tenant vs shared?) 3 Mobile lead
IR-OI-05 FIDO2 hardware key procurement approach (ship physical keys or rely on platform passkeys?) 3 Product + Ops
IR-OI-06 Opsgenie AU billing setup 3 Ops
IR-OI-07 CloudHSM cluster sizing (single cluster for all IRAP tenants, or per-tenant?) 3 Infra + Security
IR-OI-08 LocalLLMProvider (agents.md) — when/if Phase 3 adopts for sovereignty hardening 3 Product + Security

References