Who uses this?
External customers completing digital onboarding. Operations team (monitoring, exceptions). Compliance team (audit queries). IT (platform support).
Conditionally ready for ARB review. The solution architecture is sound and the approach is reasonable. Five conditions must be met before final approval:
This is a sample completed version of the Architecture Readiness Pack, showing how a realistic project submission looks when prepared honestly.
The project, organisation, team names, and data in this document are entirely fictional. They are designed to illustrate the kind of content, scoring, and conditions that appear in a real architecture review submission. This sample is intentionally not perfect — it shows open risks, pending actions, and conditional approvals because that is what honest review preparation looks like.
| Initiative | Customer Document Upload Platform Modernisation |
|---|---|
| Problem statement | The existing customer document upload capability relies on a manually operated shared file store. It has no scanning, no audit trail, inconsistent retention, and cannot support the volume or format requirements of the new digital onboarding journey. Two compliance findings in the last audit reference this capability specifically. |
| Proposed solution | Replace the file-share process with a secure, web-based upload platform integrated with the existing identity provider, a managed cloud storage service, real-time malware scanning, audit logging, configurable retention and deletion rules, and operational monitoring. |
| Architecture approach | Cloud-native on the existing approved public cloud landing zone. API-first integration with the digital onboarding portal. Identity via the existing enterprise IdP (SAML 2.0 / OIDC). Storage via a managed object storage service with server-side encryption. No new platform dependencies introduced. |
| Recommendation | Proceed — conditionally. The architecture is well-formed and appropriate for the problem. Five conditions must be met before final sign-off (see ARB Summary and Readiness at a Glance). |
| Confidence | Amber — Architecture is sound; delivery risk is in the conditions above, not in the design. |
| Decision required | ARB to approve the architectural approach and the five conditions as pre-go-live requirements, or to modify the conditions. |
| Area | Current state | Gap / impact | Severity |
|---|---|---|---|
| Upload mechanism | Customers email documents to an operations inbox or use a shared file link | No structured upload path; email attachments create data residency risk | High |
| Identity / access | No identity check on file receipt; operations manually match to customer record | No assurance that document submitter is the customer; audit finding raised | High |
| Malware scanning | None. Files are opened by operations staff on shared workstations | Malware risk is unmitigated; audit finding raised | High |
| Storage | Network shared drive; no encryption at rest confirmed | Encryption status unclear; data residency not confirmed | High |
| Audit trail | None; no log of who uploaded, when, or what was received | Cannot demonstrate compliance; audit finding | High |
| Retention & deletion | Manual; no policy enforced; files accumulate indefinitely | Regulatory retention risk; data minimisation principle breached | Med |
| Monitoring | None | No visibility of failures, volume spikes, or errors | Med |
| Operations burden | Operations team spend ~3 hours/day managing upload inbox and file routing | Avoidable manual effort; error-prone | Med |
The target architecture introduces a cloud-hosted document upload API layer, authenticated via the existing enterprise IdP. Uploads pass through a malware scanning service before being written to encrypted object storage. All events are logged to the audit trail. A notifications service sends confirmation to the customer. The operations team accesses documents through a secure review interface, not a shared drive.
| Component | Technology / service | Notes |
|---|---|---|
| Customer upload portal | Existing digital onboarding React SPA — upload widget added | No new frontend deployment; widget embedded in existing journey |
| Upload API | REST API on approved cloud PaaS (container-based) | Handles authentication, validation, scan trigger, storage write |
| Identity | Existing enterprise IdP via OIDC; JWT-validated at API gateway | No new IdP or credential store introduced |
| Malware scanning | Approved third-party scanning service via REST (already used by email platform) | Async scan with callback; file not written to final storage until scan complete |
| Object storage | Managed cloud object storage in the approved landing zone | Server-side encryption; versioning enabled; lifecycle rules for retention |
| Audit logging | Event stream to existing SIEM via approved log pipeline | All upload events, scan results, and access logged |
| Ops review UI | Lightweight internal web interface (server-rendered); role-based access via IdP | Replaces shared drive access; read-only for standard reviewers |
| Notifications | Existing email notification service (already approved) | Upload confirmation and rejection messages to customers |
| Monitoring | Platform metrics to existing observability platform | Alert thresholds to be agreed — condition C5 |
Key decisions made during architecture design. Each record captures the context, the options considered, and the rationale.
ADR-01 Storage approach
| Decision | Use managed cloud object storage in the existing landing zone rather than a managed file service or extending the existing network share. |
|---|---|
| Context | Three options were evaluated for document storage. The existing network share cannot support the security, encryption, or retention requirements. A new SaaS document management system would require a new vendor security review and budget approval. Managed object storage is already available in the approved landing zone. |
| Options | 1. Extend network share (rejected — no encryption, retention, or API access) · 2. New SaaS DMS (rejected — out of scope, new vendor, budget not approved) · 3. Cloud object storage in landing zone (selected) |
| Rationale | Managed object storage provides server-side encryption, lifecycle rules for retention and deletion, versioning, and REST API access. No new vendor. No additional budget approval required. |
| Trade-offs | Retrieval and review requires the new Ops UI rather than a familiar file browser. Operations team requires brief onboarding. |
| Status | Accepted |
ADR-02 Malware scanning timing
| Decision | Scan files asynchronously before writing to final storage; hold in a quarantine zone during scan; reject and notify customer if scan fails. |
|---|---|
| Context | Two approaches were considered: synchronous in-request scanning (simpler, higher latency) and asynchronous quarantine scanning (more complex, better customer experience for large files, better separation of concerns). |
| Options | 1. Synchronous scan during upload request (rejected — latency unacceptable for files > 5 MB) · 2. Asynchronous with quarantine zone (selected) |
| Rationale | Average document size is 2–8 MB. Synchronous scanning would add 4–12s to the upload response. Quarantine approach writes to a staging zone, triggers scan, moves to final storage on clean result, deletes on failure. Customer receives a "pending confirmation" response and an email when processing completes. |
| Trade-offs | Customer does not get immediate confirmation. Email notification adds a dependency on the notifications service. Quarantine zone must be secured and monitored separately. |
| Status | Accepted |
ADR-03 Retention policy enforcement
| Decision | Use object storage lifecycle rules for automated retention. Retention periods to be confirmed with Legal before go-live. |
|---|---|
| Context | Retention periods have not yet been confirmed by Legal. Architecture assumes 7 years for identity documents based on prior practice, but this has not been formally agreed. |
| Options | 1. Hardcode 7-year retention (rejected — not confirmed by Legal) · 2. Configurable lifecycle rules set at deployment (selected — confirmed period to be agreed before go-live) |
| Rationale | Lifecycle rules support any retention period. Deletion is irreversible — the retention period must be confirmed before rules are applied to production. |
| Trade-offs | Architecture is complete; delivery depends on Legal confirmation. This is condition C1. |
| Status | Open — pending Legal confirmation (C1) |
Three options were evaluated. Scores are 1 (poor) to 5 (excellent) against each criterion.
| Criterion | Option A Extend file share |
Option B New SaaS DMS |
Option C ✓ Cloud object store |
|---|---|---|---|
| Security / encryption | 1 | 5 | 4 |
| Audit trail | 1 | 5 | 4 |
| Retention control | 1 | 5 | 4 |
| Integration with IdP | 1 | 3 | 5 |
| Time to deliver | 2 | 2 | 4 |
| Cost (build + run) | 3 | 2 | 4 |
| Operational simplicity | 2 | 4 | 4 |
| Vendor / approval risk | 3 | 1 | 5 |
| Scalability | 1 | 4 | 5 |
| Reversibility | 4 | 2 | 3 |
| Total | 19 | 33 | 42 |
Selected: Option C — Cloud object storage in the approved landing zone. Option B scored higher on document management features but requires a new vendor security review, additional budget approval, and a longer integration timeline. The SaaS DMS capability exceeds what this use case requires. Option A fails security and audit requirements outright.
| # | Risk | Severity | Mitigation | Owner | Status |
|---|---|---|---|---|---|
| R01 | Retention rules applied before Legal confirms period. Deletion is irreversible; applying wrong retention could destroy documents needed for litigation or regulatory response. | High | Retention lifecycle rules will not be enabled in production until Legal provides written confirmation. Condition C1. | Solution Architect / Legal | Open |
| R02 | Malware scanning service unavailability. If the scanning service is down, no documents can be accepted. Upload pathway fails completely. | High | Circuit breaker pattern: if scanning service is unavailable for > 30 seconds, uploads are queued (max 2 hours). Operations notified. Runbook documented for queue drain. SLA of scanning service to be confirmed. | Platform Engineering | In progress |
| R03 | Access control model not reviewed by Security. The Ops Review UI grants access to confidential customer documents. Role model and access grants have not been through a formal security review. | High | Security review scheduled for week of 14 July. Condition C2. No access will be granted to production data before review is complete. | Security Architect | Open — C2 |
| R04 | Operations team not trained on new Ops UI before go-live. Operations team currently uses a shared drive interface. Switching cold introduces error risk in a time-sensitive process. | Med | Ops UI walkthrough session planned for 3 weeks before go-live. Parallel run for 2 weeks. Old shared drive decommissioned only after parallel run completes cleanly. | Delivery Manager / Operations Lead | Planned |
| R05 | Customer upload volume exceeds assumed peak at launch. Digital onboarding campaign planned for August may drive higher volumes than the 2,000/day assumption. | Med | Platform auto-scales within landing zone. Load tested to 5,000 uploads/day. If campaign drives higher volume, scale-up is operational within 15 minutes. Operations to monitor volume in first two weeks post-launch. | Platform Engineering | Mitigated |
| R06 | Backup and restore not tested. Storage backup is configured but no restore test has been performed. If a restore is needed and fails, document recovery is impossible. | High | Restore test scheduled for 21 July. Evidence to be provided before go-live. Condition C4. | Platform Engineering | Open — C4 |
Identity and transport controls are in place. Access control model review is pending (C2). Data classification controls are defined but not yet validated by the data governance team. Incident response runbook not yet written for this platform.
| Control area | Status | Notes |
|---|---|---|
| Authentication | Complete | OIDC via enterprise IdP. JWT validated at API gateway. No unauthenticated upload path. |
| Authorisation / RBAC | Pending review | Role model defined (Customer, Ops Reviewer, Ops Admin). Security review not yet complete. Condition C2. |
| Transport encryption | Complete | TLS 1.2+ enforced on all endpoints. Certificate management via platform service. |
| Encryption at rest | Complete | Server-side encryption enabled on all storage buckets. Key management via platform KMS. |
| Malware scanning | Partial | Scanning integrated. SLA for scanning service not yet confirmed. Fallback behaviour documented (see R02). |
| Data classification | Partial | Data classified as Confidential / PII. Data governance sign-off on classification not yet obtained. |
| Audit logging | Complete | All upload events, scan results, access events logged to SIEM. Retention of logs: 90 days hot, 2 years cold. |
| Data residency | Complete | Storage region confirmed as UK South. No data leaves the approved region. |
| Vulnerability management | Planned | Container image scanning configured in CI/CD pipeline. DAST scan scheduled before go-live. |
| Incident response | Not started | Incident response runbook for this platform not yet written. To be completed before go-live. |
| NFR | Target | Current status | Gap? |
|---|---|---|---|
| Availability | 99.5% in business hours (8am–8pm) | Platform SLA: 99.9% — confirmed | None |
| Upload response time | < 3s for files up to 10 MB (acknowledgement, not scan complete) | Load test P95: 1.8s — met | None |
| Scan completion time | < 90s for files up to 50 MB | P95 in test: 44s — met | None |
| Maximum file size | 50 MB per file; up to 5 files per submission | Validated in load test | None |
| Throughput | 2,000 uploads/day peak; 5,000 burst capacity | Load tested to 5,000/day — met | None |
| Recovery time objective (RTO) | < 4 hours | Platform failover: < 15 min. Application restart: < 10 min. — met | None |
| Recovery point objective (RPO) | < 1 hour | Storage replication: continuous. Backup: daily. RPO met if no restore needed. Restore test not yet complete — C4. | Partial |
| Data retention | Per regulatory requirement — TBC with Legal | Lifecycle rules configured; period not yet confirmed — C1 | Pending |
| Accessibility | WCAG 2.1 AA on customer upload widget | Widget accessibility review complete. Screen reader tested. | None |
| Audit trail retention | 90 days searchable; 2 years archived | Configured in SIEM — confirmed | None |
| Monitoring & alerting | Alerts on: upload failures >5%, scan failures, queue depth >100 | Metrics configured; alert thresholds not yet agreed — C5 | Pending |
Core platform and deployment readiness is in place. Support ownership, runbooks, and monitoring thresholds are the outstanding items before go-live sign-off.
| Area | Status | Notes |
|---|---|---|
| Deployment process | Ready | CI/CD pipeline deployed and tested through to staging. Blue-green deployment configured. |
| Rollback plan | Ready | Previous version retained in registry. Rollback to prior version in < 10 minutes. Tested in staging. |
| Runbooks | Partial | Upload failure runbook written. Scan failure runbook written. Queue drain runbook in draft. Incident response runbook not yet written. |
| On-call / support ownership | Pending | Platform Engineering team will cover P1/P2. L1 support ownership not yet agreed with Service Desk. Condition C3. |
| Monitoring dashboards | Ready | Upload volume, scan success rate, queue depth, error rate dashboards configured in existing observability platform. |
| Alert thresholds | Pending | Metrics available. Thresholds for alerting not yet agreed with Operations. Condition C5. |
| Operations team training | Planned | Walkthrough session scheduled for 3 weeks before go-live. Parallel run planned. |
| Customer comms | Ready | Customer-facing content updated. Email confirmation templates approved by Comms team. |
| Decommission plan | Ready | Old file-share decommission plan written. Decommission occurs after 2-week parallel run, not at go-live. |
| Backup / restore | Pending | Backup configured. Restore test not yet performed. Condition C4. |
Approve the architectural approach conditionally. The solution is appropriately scoped, uses existing approved platforms, and addresses the compliance findings that triggered this initiative. Five conditions must be met and evidenced before production go-live approval is sought. The architecture team recommends the ARB note these conditions and require sign-off from the relevant owners before the go-live gate.
| Initiative | Customer Document Upload Platform Modernisation |
|---|---|
| Review date | TBC — July 2026 |
| Presenting architect | Solution Architecture Team |
| Sponsor | Head of Digital Operations |
| Overall readiness | 72% — Amber |
| Architectural recommendation | Approve approach. Five conditions required before go-live approval. |
Conditions for go-live approval
Approvals
| Role | Name | Decision | Date | Conditions noted |
|---|---|---|---|---|
| ARB Chair | [name] | Pending | — | — |
| Security Architect | [name] | Pending | — | C2 owner |
| Platform Architecture | [name] | Pending | — | — |
| Digital Sponsor | [name] | Pending | — | — |
Glossary
| Term | Meaning |
|---|---|
| ARB | Architecture Review Board — the governance body that approves significant technology decisions |
| IdP | Identity Provider — the central identity service (Azure AD in this case) |
| OIDC | OpenID Connect — the identity protocol used for customer authentication |
| SIEM | Security Information and Event Management — the centralised audit and security log platform |
| KMS | Key Management Service — the platform service managing encryption keys |
| RTO | Recovery Time Objective — target maximum time to restore service after an incident |
| RPO | Recovery Point Objective — target maximum data loss window in the event of an incident |
| DAST | Dynamic Application Security Testing — automated security testing against running application |
Key assumptions
| # | Assumption | Owner to confirm |
|---|---|---|
| A01 | Peak upload volume will not exceed 5,000/day in the first 6 months | Digital Operations |
| A02 | Legal will confirm retention period before go-live (C1) | Legal |
| A03 | Malware scanning service is available with > 99.5% availability | Platform Engineering |
| A04 | Existing email notification service has sufficient capacity for upload confirmation volumes | Platform Engineering |
Open questions
| # | Question | Owner | Target date |
|---|---|---|---|
| Q01 | What is the legal hold process if a document needs to be retained beyond the standard period? | Legal | Before go-live |
| Q02 | Will the Ops Review UI need to support bulk download for regulatory requests? | Compliance / Digital Operations | Before go-live |
| Q03 | Is there a requirement to notify customers if their upload is rejected by the malware scanner? | Product / Digital | Before UAT |
Change log
| Version | Date | Change |
|---|---|---|
| 0.1 | May 2026 | Initial draft — context canvas and problem statement |
| 0.2 | May 2026 | Options matrix and ADRs added |
| 0.3 | June 2026 | Risk register, security and NFR sections added. Security review finding noted. |
| 0.4 | June 2026 | Production readiness section added. Five conditions identified. Readiness scoring complete. Submitted for ARB pre-review. |