AI Acceptable-Use Policy Templates: Four Verticals, Four Different Policies
Most AI acceptable-use policy templates are one generic document with the industry noun swapped, which is why they collapse the first time a regulator, examiner, or assessor reads them. This page publishes four distinct templates, as of 2026-08-28 — law firm, registered adviser / broker-dealer, healthcare organization with HIPAA-regulated workloads, and defense contractor handling CUI — each with ten numbered clauses written as adoptable policy language, and each clause annotated with why it exists in that vertical: the informed-consent gate exists because ABA Formal Opinion 512 requires one; the designated record store exists because 17 CFR 240.17a-4(f) does; the agreement-before-PHI clause exists because 45 CFR 164.502(e)(1)(i) does; the CUI Asset scoping clause exists because 32 CFR 170.19 does. Copy the template closest to your obligations, then run the adaptation steps below — a template only becomes a policy when someone owns it, trains on it, and enforces it. Have your own counsel review and tailor the template before your organization adopts it — these are starting points, not finished policies.
This page is general information about published instruments, not legal advice. Decisions about a specific engagement, account, data flow, contract, or assessment belong with your organization's own counsel and the officials who own your program.
One honest paragraph before any template: no vendor and no product — PrivateStack included — can make your organization meet the obligations these templates cite. A template changes what your people are told to do. The obligations attach to your organization and are answered by your own program — the owner, the training, the review, the enforcement. What a good policy does is make that program legible.
Four templates, because the obligations differ
Each template below leans on the vertical guide this cluster already published, and each clause's annotation uses the instruments those guides verified against primary text. Jump straight to yours:
Template: Law firm
The legal template is built around the two duties the cluster's law-firm guide separates: the ethics duty of confidentiality under Model Rule 1.6 — the subject of ABA Formal Opinion 512 — and evidentiary privilege, which is a different doctrine with a different failure mode. The clauses operationalize what Opinion 512 actually requires and put privilege on its own track, because no policy clause can resolve it. The full analysis behind these clauses is in the law-firm confidentiality guide.
01Approved tools and tiers only
Personnel may use only the AI tools, tiers, and features named on the firm's approved-tool register, for the tasks each entry approves. Consumer tiers of general-purpose assistants are not approved for any work touching client matters.
Why this clause: Supports the competence duty of Model Rule 1.1 as ABA Formal Opinion 512 applies it: the firm must reasonably understand the specific tool in use, which starts with knowing which tool that is.
02No representation information into unapproved tools
No information relating to the representation of a client may be entered into any AI tool outside the approved register, on any device or account. The prohibition covers prompts, uploads, and connected data sources alike.
Why this clause: Supports the Model Rule 1.6 duty of confidentiality — inputting representation information into a tool is exactly the act Opinion 512 analyzes.
03Risk evaluation per use case, in writing
Before an approved tool is used for a new category of matter work, the responsible lawyer must evaluate and record the risk that representation information will be disclosed to or accessed by others outside the firm — or by others inside the firm who should not see it.
Why this clause: Maps to Opinion 512's fact-driven confidentiality analysis, which depends on the client, the matter, the task, and the tool.
04Informed-consent gate for self-learning tools
Where a tool may learn from inputs and its output could disclose representation information, the client's informed consent must be obtained before that information is entered. Boilerplate engagement-letter language does not constitute informed consent.
Why this clause: Maps to the consent requirement Opinion 512 states for self-learning tools — including its statement that boilerplate provisions are not sufficient.
05Verification before anything leaves the firm
AI-assisted output must be independently verified before it is filed, sent, or relied on: citations checked against the cited authority, statements of law and fact reviewed by the responsible lawyer, and the local court's standing orders on AI disclosure checked for filings.
Why this clause: Supports the candor and meritorious-claims duties Opinion 512 analyzes under Model Rules 3.1, 3.3, and 8.4(c).
06Privilege stays on its own track
Whether routing a communication through a third-party AI tool amounts to disclosure that waives attorney-client privilege is a fact-specific question of evidence law reserved to the firm's designated counsel, matter by matter. No tool approval under this policy is a privilege determination.
Why this clause: Supports the separation the cluster's law-firm guide draws: privilege is decided by courts on specific facts, and no vendor architecture — ours included — can guarantee that privilege attaches or survives.
07Matter separation inside the firm
AI workspaces must honor the firm's ethical walls and matter-access controls: no configuration may allow representation information from one matter to surface in another matter's sessions, and the separation must be tested rather than assumed.
Why this clause: Maps to Opinion 512's point that disclosure risk includes people inside the firm who should not see the information.
08Vendor diligence before approval, re-run on change
A tool enters the approved register only after review of its Terms of Use, privacy policy, and data-handling terms — training use, retention per plane, deletion, and post-termination handling — with the reviewed versions and dates recorded. Material changes to the tool or its terms trigger re-review.
Why this clause: Supports the supervision duties of Model Rules 5.1 and 5.3 and the cloud-era vendor diligence Opinion 512 carries forward.
09Billing treatment set in advance
Time and expense treatment for AI-assisted work follows the firm's written billing policy: actual time billed, review time billed as review, general tool-learning time not billed to clients, and tool costs passed through at actual cost with disclosure.
Why this clause: Maps to the fee analysis of Model Rule 1.5 as Opinion 512 applies it.
10Training before access; logs the firm owns
No lawyer or staff member receives access to an approved tool before completing the firm's AI training, and every request must be attributable to an identified user in usage logs the firm can export — so “how was AI used in this matter” is answerable from the firm's own records.
Why this clause: Supports the Rule 5.1 and 5.3 supervision program and the audit posture courts and clients increasingly ask about.
Template: Registered adviser / broker-dealer
The financial-services template runs on two rails the cluster's recordkeeping and due-diligence guides lay down: the books-and-records duties of FINRA Rule 4511 and 17 CFR 240.17a-3 and 240.17a-4 — which attach to the record, not the tool — and the amended 17 CFR 248.30, whose safeguards program and service-provider oversight reach any AI tool that can see customer information. Regulatory Notice 24-09's reminder frames both: the existing rules continue to apply. The full analysis behind these clauses is in the FINRA recordkeeping guide.
01Written record determination per AI use
Before an AI use case goes live, the recordkeeping owner must classify in writing whether it produces or constitutes a required record — a communication sent or received relating to the firm's business, a record 17 CFR 240.17a-3 requires the firm to make, or supervisory-review evidence — and date and sign the determination.
Why this clause: Supports FINRA Rule 4511's make-and-preserve duty, which attaches to the record category, not the tool that produced it.
02Sent is preserved
Any AI-drafted communication that is sent — to a customer or inside the firm — must be preserved with any approvals of it, including principal-approval evidence where 17 CFR 240.17a-3(a)(20) requires it.
Why this clause: Maps to the 17 CFR 240.17a-4(b)(4) communications class, which expressly includes inter-office memoranda relating to the firm's business as such.
03Required records land only in the designated store
Records classified as required must be routed to the firm's designated electronic recordkeeping system meeting 17 CFR 240.17a-4(f) — never left in an application log, a chat history, or a vendor console.
Why this clause: Maps to paragraph (f)'s alternatives — a complete time-stamped audit trail permitting re-creation, or a non-rewriteable, non-erasable format — with the undertakings and immediate-production readiness it requires.
04Customer information pulls the tool into the safeguards program
The moment customer information can appear in prompts, uploads, or outputs, the AI tool and every store behind it sit inside the firm's written safeguards policies and procedures, and this policy's vendor, logging, and incident clauses apply to it in full.
Why this clause: Supports the amended 17 CFR 248.30, whose incident response program and oversight duties attach to customer information wherever it flows.
05Vendor due diligence reaches the chain
No AI vendor is approved until it has disclosed every third party that receives firm content — model providers, inference hosts, gateways, monitoring services — with what each retains and for how long, and the answers are filed with the firm's due-diligence records.
Why this clause: Supports service-provider oversight through due diligence and monitoring under the amended 17 CFR 248.30.
06The 72-hour term goes in the contract
Contracts with AI vendors that can receive customer information must require notification to the firm as soon as possible, and no later than 72 hours, after the vendor becomes aware of a breach in security resulting in unauthorized access to a customer information system.
Why this clause: Maps to the service-provider notification measure of the amended 17 CFR 248.30 — and protects the firm's own 30-day individual-notification clock.
07Attribution on every request
Every AI request must be attributable to an authenticated, individual user identity, with a timestamp and the model that served it. Shared credentials and unattributed API keys are prohibited.
Why this clause: Supports a firm's FINRA/SEC books-and-records program: a record an examiner can attribute is a record the firm can produce.
08Supervision and technology governance in the procedures
The firm's written supervisory procedures must address generative AI in the terms Regulatory Notice 24-09 uses — technology governance, model risk management, data privacy and integrity, and reliability and accuracy of the model — and review records must show the procedures operate.
Why this clause: Maps to Regulatory Notice 24-09's technology-neutral reminder that the existing rules continue to apply when firms use generative AI.
09Retention schedule and holds
Each record class carries its cited retention period — six years for (a)-class records and three years for (b)-class, in each case with the first two years in an easily accessible place, and FINRA Rule 4511's six-year default where no period is specified — and a declared litigation hold mechanically stops scheduled disposal for records in scope.
Why this clause: Maps to the preservation periods of 17 CFR 240.17a-4 and FINRA Rule 4511.
10Review before AI output reaches a customer
No AI-generated analysis or communication may reach a customer without review by a qualified person — and where the content is an advertisement or sales literature, without the principal approval the rules require. An accuracy failure in AI output does not excuse the record.
Why this clause: Supports the approval-evidence category of 17 CFR 240.17a-3(a)(20) and the reliability-and-accuracy concern Regulatory Notice 24-09 names.
Template: Healthcare / HIPAA-regulated organizations
The healthcare template follows the discipline of the cluster's PHI vendor checklist: trace the full PHI path — input, inference, storage, derived data, logs, deletion — instead of stopping at the agreement. Its clauses put the business associate agreement first because 45 CFR 164.502(e)(1)(i) does, then govern the planes where PHI actually persists. And no clause here can move the obligations of the Privacy, Security, and Breach Notification Rules off your organization. The full analysis behind these clauses is in the AI vendor checklist for the full PHI path.
01No PHI before the agreement
Protected health information may not be entered into any AI tool until the vendor's business-associate status is established in writing and a signed business associate agreement covers the specific product, tier, and configuration in use. There is no pilot exception.
Why this clause: Maps to 45 CFR 164.502(e)(1)(i): the satisfactory assurances of a written agreement come before PHI flows, and a trial period is not exempt.
02The chain has satellite agreements
PHI may flow through a vendor's subprocessors — model providers included — only where each has its own agreement down the chain, and the current subprocessor list is on file with the organization, with advance notice when it changes.
Why this clause: Maps to 45 CFR 164.502(e)(1)(ii) and 164.314(a), which push the same assurances down every hop.
03Classify the use case; de-identify only with a document
Each AI use case must be classified before launch as PHI-touching or PHI-free, and data may be treated as de-identified only under a documented determination meeting 45 CFR 164.514(b) — expert determination or safe harbor — completed before the data leaves the organization's control.
Why this clause: Supports the Privacy Rule's de-identification standard: an undocumented “anonymized” claim is a determination someone made without an expert or a document.
04Derived data is PHI until decided otherwise
Vectors, indexes, caches, and other data derived from PHI are treated as PHI — same safeguards, same agreement scope, deleted when the source is deleted — absent a documented 45 CFR 164.514(b) determination that says otherwise.
Why this clause: Supports the derived-data discipline of the cluster's PHI checklist: format is not an exit from safeguarding.
05Every log plane is inventoried
Each log plane in an AI deployment — audit, application, debug, analytics — must be inventoried as content-capturing or metadata-only, and every plane that can hold PHI carries its own access controls, encryption, retention schedule, and place in the risk analysis.
Why this clause: Maps to the audit-controls logic of 45 CFR 164.312(b): a log that holds PHI is itself a system containing electronic PHI.
06No training on PHI, contractually
The vendor's commitment that PHI is never used to train or improve models must be a contract term with protection as the default, not an opt-out — and it must bind the model provider behind the vendor, not only the vendor itself.
Why this clause: Supports protection against unauthorized uses of PHI across the whole subprocessor chain.
07Attribution and access control
Every request that can touch PHI must be attributable to a unique user identity, and vendor-personnel access to organizational content must be least-privilege, logged, and reviewable.
Why this clause: Maps to unique user identification under 45 CFR 164.312(a)(2)(i) and the audit-controls standard of 164.312(b).
08The breach clock is contractual and short
Contracts must commit the vendor to report breaches of unsecured PHI in a stated number of days well inside the 60-calendar-day outer bound of 45 CFR 164.410, with subprocessor discovery flowing to the organization on the same clock. Workforce members must report suspected incidents to the privacy officer immediately.
Why this clause: Supports the organization's own 60-day duty to individuals under 45 CFR 164.404, which does not pause while a vendor chain deliberates.
09Termination behavior in writing
At contract termination, PHI is returned or destroyed if feasible; where destruction is infeasible — backups are the honest example — the agreement's protections extend and further use is limited to what makes destruction infeasible. This behavior, with timelines, must be in the agreement before use begins.
Why this clause: Maps to the required contract term of 45 CFR 164.504(e)(2)(ii)(J).
10Training, sanctions, and the program
Workforce members complete AI-specific privacy and security training before access; violations of this policy follow the organization's sanction policy; and the AI deployment appears in the organization's risk analysis and incident response procedures.
Why this clause: Supports the administrative-safeguards program of 45 CFR 164.308 — the organization's own program, which no vendor can run.
Template: Defense contractor / CUI
The defense template applies the scoping logic of the cluster's CUI guide: content decides what is CUI, derivation is not decontrol, and any asset that processes, stores, or transmits CUI enters the CMMC Assessment Scope under 32 CFR 170.19. The clauses keep CUI inside documented assets, treat derived data and logs honestly, and route every cloud AI service through the condition of DFARS 252.204-7012 before it sees controlled content. The full analysis behind these clauses is in the CUI scoping guide for AI tools.
01CUI enters approved assets only
Controlled unclassified information may be entered only into AI tools documented as CUI Assets in the organization's CMMC Assessment Scope — in the asset inventory, the System Security Plan, and the network diagram. Every other tool is off limits for CUI, whatever its other approvals.
Why this clause: Maps to 32 CFR 170.19: components that process, store, or transmit CUI are CUI Assets, assessed against all Level 2 security requirements.
02Content decides, not the container
Personnel must treat a prompt, upload, or connected source that contains CUI as CUI from the moment it is composed. Pasting controlled content into a chat box does not re-designate it, and every store on the input path now holds CUI.
Why this clause: Maps to 32 CFR 2002.4, which defines CUI by what the information is, not which system it sits in.
03Derived output carries the control
Output derived from CUI — summaries, answers reproducing controlled parameters, generated documents — is treated as CUI unless a documented review concludes the specific output no longer contains controlled information. A transformation performed by an AI tool is not a release decision.
Why this clause: Maps to 32 CFR 2002.18: decontrol is the designating agency's decision, never a byproduct of summarizing, rephrasing, or vectorizing.
04Embeddings stay inside the boundary
Vectors and indexes built from CUI-bearing content are treated as inside the CUI boundary — same safeguards, deleted when the source is deleted — absent a documented determination otherwise, and any vendor position to the contrary must exist in writing before use.
Why this clause: Supports the scoping position of the cluster's CUI guide: nothing in 32 CFR 2002 or 32 CFR 170 recognizes a format change as an exit from safeguarding.
05Log planes are inventoried and scoped
Every log plane must be inventoried as content-capturing or metadata-only. A plane that can capture CUI is a CUI store with its own access list and retention clock, and logs generated by or ingested by security tooling enter scope as Security Protection Data even when they hold no CUI at all.
Why this clause: Maps to the asset categories of 32 CFR 170.19 and the Security Protection Data definition at 32 CFR 170.4.
06Cloud AI services meet the clause's condition first
Before any external cloud AI service stores, processes, or transmits CUI, the contracts team must obtain written evidence that the specific service offering meets the security-requirement condition of DFARS 252.204-7012(b)(2)(ii)(D) and complies with the clause's cyber-incident paragraphs. A hosting arrangement confers nothing; the evidence attaches to the offering.
Why this clause: Maps to the external-cloud condition of DFARS 252.204-7012 — a determination the contracts team makes against evidence, never a vendor's adjective.
07Fencing is documented or it is fiction
An AI tool held out of CUI scope must be fenced by written, reviewable policy, procedures, and practices that keep CUI out. “Staff are told not to paste CUI” is an intention, not an inability, and does not move an asset out of scope.
Why this clause: Maps to the Contractor Risk Managed and Out-of-Scope asset categories of 32 CFR 170.19, on the rule's own terms.
08Incidents follow the clause
Suspected or actual cyber incidents affecting CUI or covered contractor information systems must be reported through the organization's incident procedures on the timelines its contracts require, with evidence preserved for forensic analysis per the safeguarding clause's paragraphs.
Why this clause: Supports the cyber-incident reporting, preservation, and access obligations of DFARS 252.204-7012.
09No vendor statement substitutes for the program
No vendor representation, product feature, or deployment location may be cited in place of the organization's own scope, System Security Plan, assessment, and affirmation — no vendor and no product can make an organization seeking assessment achieve a CMMC Status.
Why this clause: Supports the allocation of responsibility under 32 CFR 170: the assessment and the affirmation attach to the organization.
10Training and flow-down
Personnel complete CUI-handling training covering AI use before access to any in-scope tool, and where subcontractors handle CUI in AI workflows, the substance of the safeguarding and CMMC clauses flows down to them by contract.
Why this clause: Maps to the subcontractor flow-down of DFARS 252.204-7021 and the safeguarding clause's subcontract provisions.
How to adapt a template
The clauses are the visible half. The governance below is what an examiner, an auditor, or an assessor actually probes — and it is the same five moves in every vertical.
01Name one accountable owner
General counsel or ethics counsel at a firm, the recordkeeping or supervision owner at an adviser, the privacy officer in healthcare, the CMMC program lead at a contractor. The owner approves changes to the tool register, signs the written determinations the clauses require, and answers for the policy in an exam, an audit, or an assessment. Before the policy is adopted, the owner routes the tailored template through your organization's own counsel for review — no template is finished policy language until counsel has made it yours.
02Keep the tool register outside the policy text
Every template points to an approved-tool register — tools, tiers, features, approved tasks — maintained as an appendix. Tools change monthly; obligations do not. A register the owner can update without re-adopting the policy is what keeps the policy true.
03Set the review cadence and its triggers
Review on a calendar — semiannual is a defensible default — and on triggers: a tool or its terms change materially, a new use case appears, or the instruments move. This cluster is full of recent examples: the smaller-entity date under the amended 17 CFR 248.30 arrived June 3, 2026, and the CMMC acquisition rule is phasing into contracts now. Record the date of each review; the date is the evidence.
04Gate access on training, and record it
Wire the training requirement to provisioning so no one holds access before completing it, and keep the completion records. Every vertical's supervision duty — Rules 5.1 and 5.3, written supervisory procedures, the workforce-training program, CUI handling — is demonstrated with exactly this artifact.
05Enforce it, visibly
Name the consequence path — the firm's disciplinary process, the organization's sanction policy — and monitor with logs you own, not assurances you collect. A policy no one enforces reads, in a dispute or an exam, as evidence the organization knew the risk and accepted it.
Two cluster companions do the vendor half of this work: the AI vendor security questionnaire turns the diligence clauses into 21 scored questions, and the Regulation S-P vendor due-diligence addendum carries the adviser-specific overlay, 72-hour term included.
What these templates deliberately do not do
- They do not create a program
- A policy is the instruction layer. What answers an obligation is the program that runs the instructions — the owner, the training, the review cadence, the enforcement — and that program is your organization's own.
- They do not promise outcomes
- Adopting a template settles nothing with a regulator, a court, an assessor, or an opposing party. Each vertical's instruments allocate their obligations to your organization, and no wording here moves them.
- They do not replace counsel
- Every template is general information about published instruments. Specific engagements, accounts, data flows, contracts, and assessments belong with your own counsel and the officials who own your program.
- They do not describe any product's capabilities
- The clauses restate what the instruments say, not what any vendor — us included — ships. Where a clause requires evidence, the evidence must come from the vendor you actually use, in writing.
How PrivateStack fits these templates
Several clauses ask for facts a governed deployment can simply hand you. Enterprise BYOC runs the data plane inside the customer's own AWS account and perimeter, under the access controls your security team already enforces — so the stores the templates regulate live on infrastructure you inventory and control. 100% of requests are logged and exportable: who asked what, when, against which model — the attribution evidence the logging clauses in all four templates require. On the hosted tier, inference is processed by a disclosed US-based subprocessor under contractual zero-retention terms: prompts are never stored and never used for training. For HIPAA-regulated work, the posture is the one our security page states: a signed BAA is required before processing PHI, and not every configuration is in scope. Stated plainly for the defense template: the hosted, shared tier is not offered for CUI workloads — CUI belongs on an Enterprise BYOC deployment, under a written agreement and a configuration review, per our acceptable-use policy.
And the limits, stated plainly: none of this adopts the policy for you, runs the training, or stands in for your own program — no product can, and we will not tell you otherwise. The legal, finance, healthcare, and government solution pages cover each deployment in detail, and the security page carries the full control set.
Questions people actually ask
- Are these four templates just one policy with the nouns swapped?
- No, and that is the point of publishing four. The clauses diverge wherever the obligations diverge: only the legal template has an informed-consent gate, because ABA Formal Opinion 512 requires one for self-learning tools; only the adviser/broker-dealer template routes required records to a 17 CFR 240.17a-4(f)-conformant store; only the healthcare template makes a signed business associate agreement a precondition under 45 CFR 164.502(e)(1)(i); only the defense template scopes tools as CUI Assets under 32 CFR 170.19. What the templates share — attribution, vendor diligence, log-plane inventory, training — they share because the underlying disciplines genuinely overlap.
- If we adopt a template, is the work done?
- No. A template is the instruction layer; the obligations it cites stay with your organization and are answered by the program around the policy — the named owner, the tool register, the risk evaluations and written determinations the clauses require, the training records, the enforcement path. The adaptation steps on this page are not decoration; they are the difference between a document and a defense.
- Which template applies if we sit in more than one vertical?
- Adopt per business line, not per company. A wealth-management practice inside a healthcare group runs the adviser/broker-dealer template for the practice and the healthcare template where PHI flows; a firm doing defense work adds the CUI template for the programs that touch controlled information. The shared spine — approved-tool register, attribution, vendor diligence, log inventory, training — can be one program; the vertical clauses stay distinct because the instruments behind them are distinct.
- How often should an AI acceptable-use policy be reviewed?
- On a calendar and on triggers, whichever fires first. Semiannual is a defensible calendar default for a fast-moving tool category — Opinion 512 is explicit that understanding a tool is not a static undertaking. The triggers matter more: a tool or tier change, a material terms change, a new use case, or movement in the instruments themselves — this cluster's pages record several recent examples, from the amended 17 CFR 248.30 compliance dates to the CMMC acquisition rule's phase-in.
- Can employees use personal AI accounts for work under these templates?
- Not for anything the templates regulate. All four confine regulated content — representation information, customer information, PHI, CUI — to tools on the approved register, and consumer tiers on personal accounts are exactly where the register's protections do not reach: unknown training use, unknown retention, no firm-owned logs, no agreement chain. Shadow use is where each vertical's risk actually lives, which is why every template gates access on training and makes the register the bright line.
Two companion reads finish the picture: the zero data retention vs no training guide maps the eight planes a single request can leave content on — the planes the vendor-diligence clauses make you ask about — and the closed-API comparison covers where each deployment model leaves these controls, including where the closed API wins.
Primary sources
Every regulatory statement above traces to one of these publications — the same instruments this cluster's vertical guides verified. Read the instrument before any vendor's interpretation, including ours.
- ABA Formal Opinion 512 — Generative Artificial Intelligence Tools (July 29, 2024) — The ethics guidance the legal template operationalizes: competence, confidentiality and informed consent, client communication, candor, supervision of people and vendors, and fees.
- ABA Model Rule 1.6 — Confidentiality of Information — The duty not to reveal information relating to the representation, and paragraph (c)'s reasonable-efforts duty against inadvertent or unauthorized disclosure and access.
- FINRA Rule 4511 — General requirements — books and records: make and preserve, the six-year default where no period is specified, and format and media complying with SEA Rule 17a-4.
- FINRA Regulatory Notice 24-09 — The technology-neutral reminder: existing rules and the securities laws continue to apply when firms use generative AI, with supervision expectations spanning technology governance, model risk management, data privacy and integrity, and accuracy.
- 17 CFR 240.17a-3 — Records to be made — the enumerated categories, including order memoranda, complaint records, and the communications-approval evidence of (a)(20).
- 17 CFR 240.17a-4 — Records to be preserved — the six- and three-year classes, the (b)(4) communications class including inter-office memoranda, and paragraph (f)'s electronic recordkeeping requirements.
- 17 CFR 248.30 — The safeguards and disposal rule as amended in 2024 — written safeguards policies and procedures, the incident response program, and service-provider oversight with the 72-hour notification measure.
- Release Nos. 34-100155 — Regulation S-P final rule (June 3, 2024) — The 2024 amendments behind the adviser/broker-dealer template's incident and oversight clauses: the 30-day individual-notification duty, the 72-hour service-provider measure, and the compliance dates that have now both passed.
- 45 CFR 164.502(e) — Disclosures to business associates — The satisfactory-assurances condition before PHI may flow to a business associate, and the provision pushing the same assurance down the subprocessor chain.
- 45 CFR 164.504(e) — Business associate contracts — The required contract provisions, including return, destruction, or extended protections at termination ((e)(2)(ii)(J)).
- 45 CFR 164.308 — Administrative safeguards — The risk analysis, the security-incident procedures, the workforce program, and the sanction policy the healthcare template's governance clauses map to.
- 45 CFR 164.312 — Technical safeguards — Unique user identification ((a)(2)(i)) and the audit-controls standard ((b)) behind the attribution and log-plane clauses.
- 45 CFR 164.514 — De-identification — The de-identification standard and its two exits — expert determination and safe harbor — that the derived-data clauses require in documented form.
- 45 CFR 164.404 and 164.410 — Breach notification clocks — The without-unreasonable-delay, 60-calendar-day outer bounds on the covered-entity-to-individual and business-associate-to-covered-entity legs that the breach-clock clause is built to protect.
- 32 CFR 170.19 — CMMC scoping — The asset categories the defense template scopes tools into — CUI Assets, Security Protection Assets, Contractor Risk Managed, Specialized, and Out-of-Scope — with the definitions, including Security Protection Data, at 32 CFR 170.4.
- 32 CFR 2002.4 — what CUI is — The Government-wide definition the content-decides clause restates: CUI is defined by what the information is, not where it sits.
- 32 CFR 2002.18 — decontrolling CUI — Why derivation is not decontrol: CUI stays controlled until the designating agency's decision or condition says otherwise.
- DFARS 252.204-7012 — Safeguarding Covered Defense Information — The safeguarding clause behind the cloud-condition and incident clauses, including the external-cloud condition at (b)(2)(ii)(D).
- DFARS 252.204-7021 — Contractor Compliance With CMMC Level Requirements — The acquisition clause whose flow-down the defense template's final clause carries to subcontractors handling CUI.