Security and governance
Identity, information boundaries, provider responsibilities, operating records and recovery are design requirements for technology change across wealth operations.
Operating architecture
A control is useful when it is connected to the people, systems, data and providers that operate it. The architecture makes those dependencies visible before a capability enters production.
Provider access boundary
Named, approved and revocable provider access crosses the same identity gate.
Contracted providers retain responsibility for the platforms and managed services they operate.
Audit and retention
Access, configuration, approvals, releases and exceptions produce a reviewable record.
The record has an owner, a defined purpose and an agreed retention period.
Release, rollback and recovery
Acceptance tests and release authority precede production use.
Rollback, restoration and manual fallback are defined and tested in proportion to the service.
Client and service information remains in authoritative CRM, portfolio, reporting, document and Microsoft 365 systems. Named identities pass through a least-necessary access gate before an approved interface crosses the integration trust boundary. A controlled capability operates in an agreed firm or provider environment, and an accountable person approves consequential use and production release. Approved results return to the firm record. Provider access crosses the same identity boundary. Audit and retention apply across the flow, while testing, rollback, restoration and manual fallback support release and recovery.
Control areas
The depth of work changes with the system, information and risk. These areas provide a common architecture record for decisions, implementation and review.
Establish the authoritative identity source, role and privilege model, approval path, service-account ownership, and joiner, mover and leaver controls. Access should reflect current responsibility and be reviewable without reconstructing it from individual systems.
Identify the authoritative source, sensitivity, permitted purpose, users, retention need and disposal path before information is copied or exposed to another capability. Use the smallest set of information required for the stated purpose.
Record where data is processed, how development and production are separated, which providers can gain access, and where each operating responsibility begins and ends. Contracted controls and technical configuration need to describe the same boundary.
Preserve a reviewable record appropriate to the decision: access and configuration changes, releases, approvals, material automated actions, exceptions and security-relevant events. Logs require an owner, a retention policy and a practical review path.
Define acceptance, security and recovery tests before release. Record who can approve production use, what would stop the release, how a prior state can be restored, and how restoration has been verified.
Name the incident authority, escalation route, provider contacts, recovery priorities and manual fallback for essential operations. Continuity depends on current records and rehearsed decisions as much as technology.
Specify approved information sources, permitted actions, review requirements, exception handling and the record to retain. AI assistance remains inside the institution’s authority model; qualified people approve professional judgments and consequential action.
Engagement information
These operating standards apply when agreed work requires access to firm information. The specific systems, access, handling and closeout terms are documented for the engagement before access is granted.
These standards govern Joans' engagement work. They do not make Joans the institution's continuous security-monitoring or managed detection-and-response provider.
A high-level description is enough to establish the matter. Client names, account information, credentials, investment documents and other sensitive material do not belong in the public contact path.
Before engagement work requires access, the institution and Joans agree which systems and information are needed, the permitted purpose, where work may occur, who may receive it and which retention requirements apply.
Access is assigned to named people or service identities, limited to what the work requires and removed when it is no longer needed. Shared credentials are not an acceptable access model.
The institution and its providers retain the authoritative systems and records. Engagement working material does not quietly become a replacement system of record.
Client or family material is not sent to an AI or model provider unless the institution has documented the permitted purpose, information, provider, controls, human review, retention and approval.
Return, removal or agreed retention of engagement material is established at close, together with access removal, the records the institution keeps and any unresolved exception.
Responsibility
Decisions are recorded with an accountable owner. Provider contracts, technical access and the operating model should point to the same division of responsibility.
Joans works on technology, operations, and implementation. Investment, legal, tax, compliance, and other professional judgments remain with the client and its appointed professionals.
Specialist providers remain responsible for the managed infrastructure and security services they are contracted to operate.
Security architecture and implementation may be part of a Joans engagement. Continuous security monitoring, managed detection and response, legal advice and compliance determinations require the institution's appointed providers and professionals.
Architecture record
Joans records the operating context, authority, data sources, controls, provider responsibilities, test results and rollback conditions that support a technology decision.