Practical review guide
RIA Technology and Operations Review Guide
A sound review connects the firm’s services to the systems, data, identities, providers, controls, and people that keep them running. This guide provides a structure for understanding that environment before making decisions about modernization, automation, or AI.
1 · Review the environment
Eight areas that need to be read together.
A change in one area usually alters another. A new provider can change data location and access; an automation can create a new service identity and recovery dependency. Review the relationships, not only the components.
Operating mandate
Services, commitments and accountable outcomes
Start with what the firm must deliver, who is accountable and what interruption, error or exposure would mean for clients and the institution.
Layer 1
Technology and information dependencies
- 01Systems
- 02Data
- 03Identity and access
- 04Integration, automation, and AI
Layer 2
Control, provider and operating dependencies
- 01Security and operational controls
- 02Providers and responsibilities
- 03Resilience
- 04Accountable operation
01
SystemsQuestions to resolve
Records to inspect
- Questions to resolve
- Which systems support each business service? Which record is authoritative, and who owns configuration, support, change, and lifecycle decisions?
- Records to inspect
- Application inventory, ownership, purpose, criticality, hosting, dependencies, and lifecycle status.
02
DataQuestions to resolve
Records to inspect
- Questions to resolve
- Where does client and firm data originate, move, change, and remain stored? How is it classified, checked, retained, and deleted?
- Records to inspect
- Data inventory, system-of-record decisions, information flows, classifications, retention rules, and quality controls.
03
Identity and accessQuestions to resolve
Records to inspect
- Questions to resolve
- How do employees, providers, applications, and automations authenticate? Who can grant, review, and remove standard or privileged access?
- Records to inspect
- Identity architecture, role model, privileged and automated accounts, access reviews, and procedures for granting, changing, and removing access.
04
Security and operational controlsQuestions to resolve
Records to inspect
- Questions to resolve
- Which controls prevent, detect, and contain failure or misuse? How are configuration, changes, vulnerabilities, events, and exceptions monitored?
- Records to inspect
- Control descriptions, configuration standards, logs and alerts, test results, exceptions, incidents, and remediation records.
05
Providers and responsibilitiesQuestions to resolve
Records to inspect
- Questions to resolve
- Which party operates each layer of the environment? Where do responsibilities meet, and what happens during an incident, service failure, or exit?
- Records to inspect
- Contracts, responsibility map, service commitments, provider and subcontractor dependencies, assurance reports, escalation routes, and terms for retrieving data or changing provider.
06
Integration, automation, and AIQuestions to resolve
Records to inspect
- Questions to resolve
- How do systems and people exchange information? What data, credentials, approvals, validation, exception handling, and fallback does each capability require?
- Records to inspect
- Integration inventory, data mappings, permissions, execution history, review points, failure paths, and records of automated or AI-assisted actions.
07
ResilienceQuestions to resolve
Records to inspect
- Questions to resolve
- Which dependencies could interrupt a critical service? What can be restored, how quickly, from which records, and when was recovery last tested?
- Records to inspect
- Continuity plans, backup and restoration records, expected restoration times and data-loss limits, dependency risks, test results, and communication procedures.
08
Accountable operationQuestions to resolve
Records to inspect
- Questions to resolve
- Who makes decisions, accepts risk, runs the service, monitors performance, and owns corrective action after implementation?
- Records to inspect
- Decision rights, operating procedures, control owners, training, change records, service measures, issue management, and acceptance criteria.
An operating mandate connects through technology and information dependencies, control and provider dependencies, and a cross-layer connection rail to eight review areas and their supporting operating records.
2 · Make the architecture legible
An application diagram is only one view.
The architecture becomes useful when leaders can see how the firm operates, how information and technology support it, and where control and responsibility sit.
One accountable operating decision
A named owner accepts the result, required controls, operating responsibilities and evidence.
01
Operating view
The services the firm must deliver, the people responsible for them, the commitments involved, and the consequences of interruption or error.
02
Technology and information view
Applications, infrastructure, providers, data stores, interfaces, automations, AI services, and the dependencies between them.
03
Control and responsibility view
Identities, permissions, trust boundaries, approvals, monitoring, recovery, operating records, and the party accountable for each control.
The three architecture layers connect service commitments, technology dependencies, information, controls and ownership, then converge around the same accountable operating decision and its retained evidence.
Mark uncertainty explicitly. An unknown integration, unowned administrator account, or undocumented provider boundary is a finding, not a reason to guess.
3 · Examine proposed change
Evaluate a capability in the environment it will enter.
Product features matter, but they are not the whole decision. The firm also needs to understand architecture, information exposure, control design, responsibility, implementation, and ongoing operation.
01
Intended result
State the operational or client-service result, who is accountable for it, and how the firm will know the change is useful.
02
Architectural fit
Show what the change connects to, replaces, duplicates, or depends on, including any new concentration of risk.
03
Data and access
Identify the information involved, where it will go, the identities and permissions required, and the rules for retention and deletion.
04
Control design
Define approval, validation, logging, monitoring, exception, recovery, and escalation before the capability is relied upon.
05
Operating model
Name who will administer, support, monitor, change, and retire the capability, including provider responsibilities and required operating records.
06
Implementation and adoption
Plan configuration, migration, testing, training, release, rollback, and acceptance in a sequence the firm can control.
Where AI is involved
Examine the service and model, the information it receives, how outputs are evaluated, what actions it may take, how activity is logged and monitored, and what happens when the service is wrong or unavailable. AI should strengthen an understood operating design, not substitute for one.
4 · Preserve the reasoning
A sound review leaves a usable record.
The record should be clear enough for another responsible person to understand what was found, what was decided, and what must be operated or revisited.
Current-state architecture
The operating, technology, information, control, and responsibility views, with assumptions and gaps clearly marked.
Risk and dependency record
Material weaknesses, concentrations, unsupported technology, control exceptions, provider dependencies, and unresolved ownership.
Decision record
Options considered, sources used, constraints, trade-offs, required controls, accountable decision-maker, and review date.
Implementation and operating plan
Sequence, owners, validation, migration, communications, training, support, monitoring, recovery, and acceptance into normal operation.
Continue