Architecture Review Board Decision on a Mortgage Platform With a Data Residency Problem

The stale threat model is the first problem, because every downstream test scope depends on it. A threat model that predates the KYC integration cannot be used to justify a test plan. Re-baseline the architecture first: an as-built data flow diagram, a component inventory with trust boundaries, and a change log since the original model. Then update the threat model specifically around the new trust boundary: identity data crossing a jurisdictional border, a vendor-operated store outside Summit's control, vendor staff access, backup and replica locations, and the deletion conflict between the localization law and the seven-year retention obligation. Add the API authorization threats that bit the sister platform, since that is a demonstrated failure mode in this organization.

Evidence per claim, with the method named:

• Design completeness: architecture definition, as-built data flows, updated threat model, and a requirements traceability matrix mapping each regulatory and internal requirement to a design element and to a verification method (analysis, inspection, demonstration, or test).
• Control implementation: configuration baselines and configuration review evidence for identity, encryption, logging, and network policy - inspected, not asserted.
• Authorization correctness: targeted API authorization testing with an explicit matrix of role, object, and tenant combinations, including horizontal and vertical escalation and object-reference manipulation. This is a test, not an inspection.
• Data residency: vendor data flow documentation plus technical evidence of where data is stored and whether it replicates, corroborated by egress and storage logs.
• Retention and examiner retrieval: a demonstrated retrieval of a seven-year-old record within the five-day requirement, timed and witnessed.
• Independent review: for a Tier-1 platform, an independent reviewer signs the traceability matrix, not the project team.

Sequence: re-baseline and threat model now, configuration and design inspection at the review, penetration test and authorization matrix after the review, retest of criticals before cutover. The current calendar has no retest window, which is a plan defect that must be fixed by moving the test earlier or moving the date; a test with no time to fix and retest is documentation, not verification.

Decision: approve the architecture direction with blocking conditions. Do not approve go-live. These are different decisions and conflating them is how boards end up owning risks nobody accepted.

Blocking conditions (cutover cannot proceed without closure):

1. Data residency. The vendor's cross-border store and replica appear to conflict with the localization law. This is a legal question, not a risk the business can self-accept. Condition: a written legal or data protection officer opinion on whether the vendor's logs, backups, and support access constitute copies requiring in-country retention, plus either vendor reconfiguration to in-country storage and no cross-border support access, or a documented lawful basis. Owner: general counsel with the DPO. This is not waivable by the CIO.
2. Critical penetration findings with no retest. Condition: the test moves earlier, and every critical and high finding is either remediated and retested or has a compensating control validated by the security architect and accepted in writing by the accountable executive. Owner: platform owner and CISO.
3. Unaccepted waivers. Each of the six waivers must name an acceptor with the authority to accept that class of risk, state a compensating control, and carry an expiry date. A waiver without a named acceptor is not a waiver; it is an unowned risk.

Non-blocking conditions: medium findings get a dated remediation plan with owners and a monthly report to the risk committee.

Enforcement mechanisms, because a condition without a gate is a wish: the conditions become entries in the cutover readiness checklist with named owners and dates, verified by an independent reviewer who is not on the project; the go-live authority is explicitly the accountable executive, not the delivery lead; the board's dissent and the security architect's position are minuted, so the record shows what was known and when. Finally, schedule a post-implementation review at 30 and 90 days that specifically tests the compensating controls, since compensating controls decay faster than implemented fixes.

Treat vendor assertions as claims requiring independent corroboration, and separate contract, attestation, documentation, and technical testing.

Demand from the vendor and from legal: a current SOC 2 Type II with a scope that actually covers this service (check the system description for the specific product and the complementary user entity controls, which are frequently ignored); ISO 27001 certification with the statement of applicability scope checked; the subprocessor list with locations; the data processing agreement clauses on data location, breach notification timelines, return and deletion, and audit rights; and a written data flow map showing primary store, replicas, backups, logs, support access, and disaster recovery region. Many residency failures are not in the primary database at all but in logging pipelines, backups, and offshore support tooling.

Demand from legal: an opinion on whether the localization law applies to the vendor as a processor, to copies and replicas, and to logs containing identity data; and how the law interacts with the seven-year retention requirement. Retention and localization are frequently in direct tension, and the resolution must be recorded before go-live, not after the first examiner request.

Test yourself rather than accept:

• Inspect the tenant configuration for region pinning of storage, backup, and logging, and verify no cross-region replication is enabled.
• Review egress logs and, if available, cloud flow logs for traffic to endpoints outside the required jurisdiction during a defined observation window, including a support session.
• Have the vendor demonstrate a support session and record where the session is terminated and which personnel can view records.
• Execute an examiner-style retrieval request for a sample record and time it against the five-business-day requirement, including the part of the chain the vendor controls.
• Test deletion: submit a deletion request for a test subject and verify the record is gone from primary, replicas, backups per the agreed schedule, and logs.

Report to the board as a residual risk statement, not a compliance statement: what was verified, what was accepted on vendor assertion, what remains unknown, and the conditions under which the position would change. That is the only form of assurance a board can actually rely on.