Security Standards

01Scope, application, and openness

This document states the security controls the Adopting Entities hold themselves to when handling client data.

It is a standard each entity adopts, not a policy issued by a parent company. The Adopting Entities are separate legal entities under the common control of the same individual. Nothing here asserts that any Adopting Entity owns, controls, or is liable for another, or that any holding company or group structure exists between them. Where you contract with one Adopting Entity, that entity is your counterparty and the only entity you deal with, and its own agreement governs.

One document covers all of them deliberately. A security standard maintained separately per entity drifts, and drifted standards are worse than none.

It applies to every employee, contractor, and other individual performing work for an Adopting Entity, whatever entity engaged them, and to every automated agent operating on their behalf under Section 13.

It is incorporated by reference into client agreements rather than restated inside them. Security controls change faster than contracts do, and one document that updates cleanly is safer than the same paragraph copied into a dozen agreements that then drift apart.

This document states what is true across all engagements. It does not list the specific systems, vendors, or people involved in any one engagement. Those are recorded in the schedule attached to that engagement's own agreement, which stays confidential between the Adopting Entity and that client.

Open to review

This document is published rather than supplied on request. Anyone may read it: our own people, our contractors, a client, a client's compliance or security reviewer, or a prospective client deciding whether to work with us. No request, approval, or non-disclosure agreement is needed to read it, and we will not send a different version to anyone.

Where a client agreement imposes a stricter requirement than this document, the client agreement controls.

02Change control and the ratchet

Any Adopting Entity may update this document. Every version carries a version number and date, and every published version stays available at its own address permanently, so you can always retrieve the version in force when your agreement took effect.

One rule governs every change: a new version may not reduce the protection afforded to client data below the version in force on a given client's effective date. Protection moves in one direction. A change that would lower it is not a new version of this document, it is an amendment to that client's agreement, and it requires that client's signature.

Material changes are notified to affected clients in writing at least thirty days before they take effect. A client who does not accept a material change may terminate without penalty.

Movement in Section 14 from building to in force is not a reduction in protection and needs no notice, but is reported at the annual review.

03Identity and access

Access to client data is granted on a least-privilege basis. Read-only access is the default wherever the work permits it. Access is scoped to the specific systems and records the work requires, and is revoked within two business days of the end of the need.

Every account with access to client data is protected by phishing-resistant multi-factor authentication, meaning a passkey or a time-based authenticator application. SMS and voice one-time codes are not used on any account with access to client data where the system offers an alternative. Where a system offers no alternative, that system is identified in the engagement schedule with the reason and the compensating control applied.

Credentials are generated uniquely per system, never reused, and stored only in an encrypted credential manager. Credentials are never stored in plaintext, in shared documents, in message threads, in source code, or in configuration files committed to version control.

Named accounts and group-based access

Access is granted to a named person, not to a role mailbox or a shared identity, wherever the platform supports it.

Where a platform supports it, access is granted through group membership rather than by provisioning each system individually. A person is added to the group matching their role and scope, and removed when the engagement ends. Membership changes take effect without rebuilding or re-sharing the underlying resources, and removal revokes access everywhere that group grants it. This applies to internal and external people alike, and it is what allows a contractor to be added and removed without dismantling a project.

Platforms that support only one login

Some platforms, including several social and marketing tools, support only a single set of credentials. For every such platform:

1. It is named in an internal register of single-login platforms, with the people who currently hold access.
2. The credential lives only in the encrypted credential manager and is shared through that manager's own per-person access controls rather than by sending it, so access can be withdrawn from one person without issuing a new credential to everyone else.
3. The credential is rotated when any person with access stops needing it, and on a periodic schedule regardless.
4. Multi-factor authentication is enabled, using a shared authenticator seed held in the credential manager where the platform offers nothing better.
5. No client data of either tier in Section 5 is accessible through a single-login platform. If an engagement would require that, the platform is not used for it.

Group membership routes access. It does not solve a shared password. Where both apply to the same platform, both sets of controls apply.

Review

Access to client data is reviewed against the engagement schedule at least quarterly, and any access no longer required is removed. Group membership is reviewed in the same pass.

04Devices, location, and travel

Client data is accessed only from devices under the control of an Adopting Entity or, for contractors, from devices meeting the requirements in Section 7. Every such device has full-disk encryption, an automatic screen lock with a short timeout, a current supported operating system with security updates applied, and remote wipe capability.

Location and travel

Work is performed from wherever the person is, including while travelling. Location alone is not a restriction, provided the device and network requirements here are met.

Client data is not accessed from a device the person does not control. That includes hotel and airport business-centre computers, client workstations used by others, borrowed machines, and any shared or public terminal. A controlled device on an untrusted network is fine. An untrusted device is not. On an untrusted network, client data is accessed only over an encrypted tunnel.

Access from outside the United States

Cross-border access is a contractual question before it is a technical one.

For Tier 1 data as defined in Section 5, access while travelling abroad is permitted under the device and network rules above unless the client agreement says otherwise.

For Tier 2 data, cross-border access is governed by the client agreement and is frequently prohibited without the client's prior written approval. A business associate agreement typically bars access to protected health information from outside the United States absent that approval, and the approval has to exist before the travel rather than be explained after it. Where no approval exists, access to Tier 2 data is suspended for the duration of the trip. Any standing approval for a named country is recorded in the engagement schedule.

05What we mean by client data

Two different things get called client data, they carry different risk, and conflating them is how regulated information ends up somewhere it should not be. This section separates them.

5.1 Tier 1: your data

Tier 1 is the client's own business information. Pricing, strategy, financials, vendor and partner relationships, technology and systems detail, internal processes, unreleased work, and anything else not public that the engagement touches.

This is the day-to-day operational data of working together. Confidentiality obligations and the applicable non-disclosure agreement govern it.

5.2 Tier 2: your clients' data

Tier 2 is data about identifiable people the client serves rather than about the client's own business. Their patients, customers, members, clients, employees, or applicants.

If our client is a business and that business holds information about the individuals it serves, that information is Tier 2 whether the relationship is business to consumer or business to business. A surgical practice holds patient records. An ecommerce brand holds customer names, addresses, and order history. A staffing firm holds applicant files. All of it is Tier 2.

Tier 2 does not depend on a regulation applying. A customer list with no statute attached to it is still Tier 2, because the people in it did not choose to do business with us and have no relationship with us to rely on. Where a specific regime does apply, HIPAA being the common case, it adds obligations on top of Tier 2 and is carried by the governing agreement, usually a business associate agreement. It does not create a third category and it does not change how the data is handled here. Regulation raises the floor; it never defines it.

Tier 2 carries everything in this document that applies to Tier 1, plus 5.4 through 5.6, plus whatever the governing agreement adds.

Where it is unclear which tier a dataset falls into, it is handled as Tier 2 until the client confirms otherwise. The cost of over-protecting Tier 1 is a slower workflow. The cost of under-protecting Tier 2 is a reportable breach affecting people who never had a say.

5.3 Handling and segregation

Client data of either tier is confined to the systems identified in that engagement's schedule. It is not copied, moved, or duplicated into any other system.

Client data is not stored in any general knowledge-management, note-taking, research, or personal productivity environment an Adopting Entity operates. Those environments support internal work and are out of scope for client data of either tier. This is a hard boundary, not a preference, and it holds regardless of how convenient the exception would be. Environments of that kind typically carry version history, sync, and backup, which makes a mistake there difficult to undo.

Client data is not transmitted through consumer messaging applications, personal email accounts, freelance or staffing platform messaging, or any file-sharing service not named in the engagement schedule.

Each client's data is kept logically separated from every other client's. Data from one engagement is never used in another. Only the minimum necessary is requested, accepted, or retained, and where a client sends more than the engagement requires we say so and do not retain the excess.

Where work can be done without live client data, it is scoped that way. De-identified, synthetic, masked, or sample data is used in development, testing, demonstration, and documentation wherever it is sufficient.

5.4 Working inside client systems

Much of the work happens inside the client's own platform: an electronic health record, a practice management system, a booking or payments platform, a data warehouse. Tier 2 data is frequently visible there.

The default is that Tier 2 data stays in the client's system and the work happens in place. Nothing is exported, downloaded, screenshotted, copied, or synchronised into an Adopting Entity's systems unless that movement is named in the engagement schedule, limited to what the task requires, and subject to a stated retention and destruction schedule.

Where a working copy is genuinely necessary, it is de-identified first if the task permits, it lives only in a named system, and it is destroyed on completion with the destruction recorded.

Access to the client's platform uses credentials the client issues, scoped to the minimum the work requires, under a named individual account, subject to Section 3. Where a client can only issue a single shared login to their own platform, that is recorded in the engagement schedule as a client-side constraint and the single-login controls in Section 3 apply.

5.5 Byproducts

The hardest part of handling Tier 2 data is not the database. It is everything the work leaves behind.

Regulated and personal data ends up in places nobody chose to put it. The following are treated as capable of containing client data and are handled as the tier of the data they may contain:

1. Screenshots, screen recordings, and screen-sharing recordings.
2. Exports, reports, query results, and test records, including ones generated only to verify that something works.
3. Documentation, standard operating procedures, runbooks, training material, and worked examples.
4. Prompts, system instructions, context files, and the configuration of any automated process.
5. The working state, memory, and conversation history of any AI tool or agent.
6. The logs, outputs, and error messages of any scheduled task, batch job, or agent.
7. Support tickets, email threads, chat messages, and meeting notes and transcripts.
8. Spreadsheets and documents created to work something out, including ones meant to be temporary.

Documentation, SOPs, and worked examples are written with synthetic or de-identified content. A real record is never used as an illustration, and a screenshot containing real records is never pasted into a procedure document.

Where a byproduct does contain Tier 2 data it is treated as Tier 2 data from that moment: moved into a named system or destroyed, the exposure assessed under Section 9, and notified if the governing agreement requires it. A byproduct that has reached a general knowledge-management or productivity environment contrary to 5.3 is treated as an incident under Section 9, not as a filing error.

5.6 Transient processing and AI tooling

Data passing through an approved tool to produce a result is not storage, and is permitted, but only on all of these conditions:

1. The tool is named in the engagement schedule and is covered by whatever written agreement the data requires, including a business associate agreement where protected health information is involved.
2. The provider contractually excludes the data from model training and from retention beyond what is operationally necessary to return the result.
3. The result is treated as a byproduct under 5.5 and scrubbed or placed in a named system before it is used or stored anywhere else.
4. Conversation history, session logs, and any provider-side retention are recognised as storage rather than transience, and sit within the retention position stated for that tool.

"We do not store it" is not accurate merely because no Adopting Entity's database holds the data. Where data has passed through a third party, that third party's retention is the position that matters, and that is what we state to the client.

Where a client's own platform connects to or integrates an AI service as part of the engagement, that service is a subcontractor under Section 7, is named in the engagement schedule, and is subject to the AI Use Standards, which carry the full detail on AI and automated processing.

06Encryption

Client data is encrypted in transit using current industry-standard transport encryption, and at rest using current industry-standard algorithms, on every system named in the engagement schedule. Encryption keys are managed separately from the data they protect and are not stored alongside it or in the same backup set. Where a client system does not support encryption at rest, that is named in the engagement schedule with the compensating control.

07Contractors, subcontractors, and third parties

The Adopting Entities engage contractors, including individuals sourced through freelance and staffing platforms. Before any such individual is given access to client data, and as conditions of that access:

1. A written agreement is executed with the individual or that individual's own entity, carrying confidentiality and data-handling obligations at least as restrictive as those the Adopting Entity owes the client. A platform's terms of service do not satisfy this. The platform is a sourcing channel, not a counterparty.
2. The individual is named in the engagement schedule before access begins, and the client has had the opportunity to object.
3. The individual is located in and works from the United States, unless the client has given prior written approval otherwise.
4. The individual has completed data-handling and, where applicable, HIPAA awareness training, and the Adopting Entity retains the record.
5. Access is granted through group membership under Section 3 where the platform supports it, under an account the Adopting Entity issues and controls, so that it can be withdrawn in one action.
6. Work is performed inside systems named in the engagement schedule. Client data does not pass through platform messaging, platform storage, or the individual's own tooling.
7. Access is revoked within two business days of the end of the engagement, and the individual certifies destruction of any local copy.

Contractors are given Tier 2 data only where the task genuinely requires it. Where the work can be done without client data, or on de-identified data, it is scoped that way under 5.3.

Any vendor that stores, processes, or transmits client data on an Adopting Entity's behalf, including cloud storage, backup, hosting, automation, and AI providers, is treated as a subcontractor and named in the engagement schedule. The Adopting Entity remains responsible for the acts and omissions of its contractors and subcontractors as if they were its own.

08Logging and monitoring

Logging is maintained sufficient to reconstruct who accessed client data, what they accessed, and when, on systems where that logging is available. Logs are retained for the term of the engagement plus six years, are protected against alteration, and are not stored only on the system they describe. Where a system does not produce access logs of that quality, that is recorded in the engagement schedule with the compensating control.

Automated alerting covers authentication anomalies and failures in the systems that protect or back up client data. Where an alerting mechanism could itself fail silently, the monitor for it is hosted outside the system it watches, so a failure produces an alert rather than silence.

09Incident detection and response

An incident is treated as discovered on the first day it is known, or by exercising reasonable diligence would have been known, to an Adopting Entity or to any of its personnel or contractors other than the person who caused it.

Client notification timelines are set by the applicable client agreement, not by this document, and the agreement's timeline governs regardless of the state of internal procedure. Where an agreement sets no timeline, the affected client is notified without unreasonable delay and in no case later than five business days after discovery. Evidence, including logs and affected records, is preserved from the point of discovery.

Every incident is documented at the time it occurs, covering what happened, when it was discovered, what data was involved, what was done, and what changed as a result. That record is produced whether or not a written procedure exists at the time, and is retained for six years.

A written incident response procedure covering detection, containment, investigation, notification, and remediation is maintained and tested at least annually. Section 14 gives its current status.

10Backup and continuity

Systems holding client data are backed up on a schedule appropriate to the engagement, with backups encrypted and stored separately from primary systems. Backup success is monitored, and a backup that has not completed within its expected window raises an alert. A backup system that reports nothing is treated as failed, not as healthy. Restoration is tested at least annually. Backups carry the same access, encryption, and destruction requirements as primary systems.

11Retention and destruction

Client data is retained only as long as the engagement requires, or as long as the client agreement or applicable law requires, whichever is longer. A retention and destruction position is recorded for each system named in the engagement schedule before client data is placed in it, so destruction at the end of an engagement is a known operation rather than a discovery exercise.

On termination, client data is returned or destroyed as the client agreement specifies. Destruction renders the data unusable, unreadable, and indecipherable, and covers all copies, including byproducts under 5.5 and copies held by contractors and subcontractors. Where data exists only in immutable backup, version history, or legal-hold systems and cannot be selectively destroyed, we say so in writing, identify what is retained and why, and continue to apply every control here to it for as long as it exists. Written certification of what was returned, what was destroyed, by what method, and on what date is provided to the client.

12Risk management and review

A documented risk analysis is maintained covering the systems used to handle client data, reviewed at least annually and updated when the systems or the data change materially. Written policies and procedures, and the records demonstrating they were followed, are retained for six years from creation or last effective date, whichever is later.

This document is reviewed at least annually and within thirty days of any material change in applicable law.

Counsel review

The annual review includes review by legal counsel. Counsel review of every standing policy is deliberately batched into a single annual pass rather than run document by document as each one changes. Counsel sees the whole set in context rather than in fragments, the policies have had a year to settle in practice before they are examined, the cost is predictable, and the Adopting Entities are not paying for repeated partial reviews of documents still in motion. An interim review is commissioned outside that cycle only where a change in law or a material incident warrants it.

The counsel review status in the control block at the top of this document states where that stands as of the current version.

Clients may request, no more than once per calendar year, a written attestation that these standards are being met, together with the then-current Section 14.

13Automated agents, oversight, and regulatory watch

The Adopting Entities run automated agents as a normal part of operating. Some monitor security posture and regulatory change. Others carry out business work. This section governs both, and it runs in two directions: this document is the authority agents operate under, and agents are part of how this document stays current.

13.1 This document governs the agents

Every agent and sub-agent with access to client data, or operating on a system that holds it, is bound by this document exactly as a person would be. An agent is not a loophole in a control, and the fact that work was performed by software is never a reason a control did not apply.

The following are conditions of an agent operating on client data:

1. It has a named accountable human. Accountability sits with a person, never with an agent, and never with a team in the abstract.
2. It is registered, with its purpose, scope, the systems it touches, and the data tier it may handle recorded before it runs.
3. It operates under scoped credentials of its own under Section 3, not under a person's general access, so its reach can be audited and withdrawn independently.
4. It touches Tier 2 data only where it is named in the relevant engagement schedule.
5. Its prompts, configuration, working state, logs, and outputs are byproducts under 5.5 and are handled as the tier of the data they may contain.
6. It reports; a person decides. No agent grants access, changes a security control, alters a client-facing commitment, or approves its own output.
7. Its authority is bounded in writing. An agent that cannot determine whether an action is in scope stops and escalates rather than inferring permission.

This is the guardrail set. Human judgment owns the decision and stays accountable for it; the agents make the execution of that judgment faster and more consistent. Written policy is what makes that division real rather than assumed, which is why these rules are published rather than held internally.

13.2 The agents help maintain this document

A defined set of agents monitors, on a stated cadence:

1. Change in applicable law and regulation at federal, state, and international level, covering health information privacy and security, data protection generally, and the developing law on artificial intelligence and automated processing.
2. Published guidance and enforcement activity from the relevant regulators, which frequently signals what will be expected before a rule changes.
3. Material change to the terms, security posture, retention position, or training practices of any vendor or AI provider named in an engagement schedule.
4. Published vulnerabilities and advisories affecting systems in use.
5. The health of the controls in this document, including backup completion, authentication anomalies, and access that has outlived its need.

Those agents read this document as their reference for what the standard currently is, and they raise a proposed change when they find drift between the standard and either the law or practice. A proposed change is a recommendation. It becomes a new version only when the accountable human approves it, and only under the ratchet in Section 2. No agent publishes a version of this document, and no agent weakens a control.

An agent whose job is to notice a failure is never hosted by the system it watches, so a failure of that system produces an alert rather than silence.

13.3 What happens with the output

A development requiring a change to this document triggers the Section 12 review within thirty days rather than waiting for the annual cycle. A development affecting a specific engagement is raised with that client rather than held until they ask.

Monitoring is paired with continuing education rather than treated as a substitute for it. Staying current is explicit work with time allocated to it, not a byproduct of doing engagements.

14Implementation status

A security standard that overstates what is operating is worse than one that does not, particularly where the standard is incorporated by reference into a contract. Sections 1 to 13 state what we commit to and are building toward. This section states where we actually are.

The direction is settled and the standard above is the target. The work is continuous and progress is reported at each annual review. Where a control is partial or building and an engagement depends on it, the gap and the compensating control are stated in that engagement's schedule before client data is accepted. No client is left to discover a gap.

The current version of this table is always the one published here, and a client may ask for it at any time.

15Known limitations

These are stated plainly because a client evaluating an Adopting Entity should not have to discover them later.

No Adopting Entity is SOC 2 certified or HITRUST certified, and none holds any third-party security certification. The controls here are self-attested and are not a substitute for an independent audit.

The Adopting Entities are a small organisation. There is no security operations centre, no dedicated security staff, and no 24-hour coverage. Detection depends on automated alerting and periodic review rather than continuous human monitoring, and response times reflect the size of the organisation.

Several controls here are not yet fully implemented. Section 14 says which, and is part of this document rather than an appendix to it. A client relying on a specific control should read Section 14 before relying on it.

Separation of duties is limited by headcount. Where a control would normally require two people, it is implemented through logging and after-the-fact review instead, which detects a problem rather than preventing it.

The Adopting Entities depend on third-party platform providers for the security of the underlying infrastructure they use, and do not control or audit those providers' internal controls.

Where a client's own security requirements exceed what is described here, the Adopting Entity will say so rather than accept an obligation it cannot meet.