Data Handling Policy

Ops Systems Lab LLC • Effective and last updated July 16, 2026

OSL’s default is simple: collect less, use synthetic or redacted data where possible, work in the client’s environment where practical, grant only needed access, and remove access and working copies after the work ends.

1. Purpose and scope

Ops Systems Lab LLC (“OSL,” “we,” “us,” or “our”) designs, configures, tests, documents, and supports operations workflows using Microsoft 365 and Microsoft Power Platform. This Data Handling Policy describes our baseline practices for information received or accessed during business development, discovery, proposals, workflow design, implementation, testing, handoff, and limited post-launch support.

This Policy is a public description of baseline practices. It is not a data-processing agreement, business associate agreement, security certification, or guarantee against incidents. It is not incorporated into a client agreement unless that agreement expressly says so. A signed Master Services Agreement, Statement of Work, data-processing addendum, or security addendum controls if it states different or stricter requirements.

2. Roles and ownership

The client retains ownership of Client Data and determines the lawful business purposes for which it is used. OSL accesses or processes Client Data only to provide the agreed services, follow documented client instructions, protect the engagement, and comply with law. For solutions built in a client-controlled Microsoft 365 tenant, the client remains responsible for tenant governance, identities, permissions, retention, backups, audit settings, legal bases, notices, and end-user administration unless the Statement of Work expressly assigns a task to OSL.

3. Data categories

4. Core handling principles

• Data minimization — request only information needed to understand, build, test, document, support, or administer the agreed work.

• Synthetic-first testing — use fictional, de-identified, masked, or redacted records whenever they can test the same requirement.

• Client-environment preference — configure production solutions in the client’s approved tenant or environment where practical, rather than exporting live data to an OSL-controlled environment.

• Least privilege — request only the roles and permissions needed for the current task and remove them when no longer needed.

• Purpose limitation — do not use Client Data for advertising, resale, unrelated product development, or an unrelated client’s work.

• Separation — keep client materials in approved business systems and separate them from personal accounts and unrelated client work.

• Documented boundaries — identify allowed systems, users, data categories, and access methods in the Statement of Work or project record.

5. Access and credentials

• OSL will not request or store a client’s password, MFA code, recovery code, API secret, or private key.

• Access should use a named account, client-issued account, guest account, delegated role, role-based group, screen share, or other approved method.

• Shared generic accounts should be avoided. Administrative access should be time-limited and used only when necessary for the agreed task.

• The client controls account creation and revocation in client systems. OSL will promptly stop using access when the task or engagement ends and will cooperate with revocation checks.

• OSL business accounts use authentication and access controls appropriate to the information, including multi-factor authentication where supported.

6. Storage, devices, and transmission

OSL stores working materials only in approved business systems reasonably suited to the information, such as Microsoft 365 business services, the client’s Microsoft 365 tenant, and other contracted business providers identified for the engagement. Client materials are not intentionally stored in personal email, personal consumer-cloud accounts, or unsecured personal messaging applications.

Information should be transmitted through authenticated business services, approved client systems, secure file links, or another agreed channel. OSL relies on the encryption, availability, logging, and security features supplied by those platforms and applies available settings appropriate to the engagement. When local work is necessary, it should occur on an authenticated business device with current security controls, and unnecessary local copies should be removed after transfer or use.

7. AI-assisted and automation tools

OSL may use AI-assisted or automation tools for drafting structure, code assistance, documentation, summarization, quality checks, or similar productivity tasks. The default is to use public information, OSL information, synthetic data, or content that has been redacted or de-identified.

OSL will not intentionally submit Client Confidential Information, identifiable Client Data, credentials, or Restricted Data to a generative AI service unless the client expressly authorizes the specific use in writing, the service is approved for that use under appropriate business terms, and the parties document any additional safeguards. A client may prohibit or narrow AI-assisted use in the Statement of Work. AI output is treated as draft work and must be reviewed before it is relied upon or placed in production.

8. Service providers and subcontractors

OSL uses service providers for functions such as website hosting, business email, cloud productivity, document storage, accounting, e-signature, security, and other business operations. They may process information only to provide their services under their own contracts and privacy/security terms. If OSL uses a subcontractor for material client-facing delivery or grants one access to Client Data, OSL will remain responsible for its contractual obligations and will disclose or obtain approval when the client agreement requires it.

9. Retention, return, and deletion

The client remains responsible for its authoritative records, production data, backups, retention policies, and legal holds in client-controlled systems. OSL retains working copies only as long as reasonably necessary for delivery, the agreed support period, security, billing, legal obligations, or dispute resolution.

Unless a signed agreement requires a different period, OSL’s target is to delete or de-identify unnecessary project working copies within 90 days after the engagement and included support period end. This target does not require deletion of contracts, invoices, proof of delivery, approval records, security records, records required by law, or information subject to a legal hold. Routine backups may retain residual copies until overwritten under the provider’s normal cycle; restored backup data remains subject to the same restrictions.

Upon a reasonable written request, OSL will return or provide an available export of agreed client materials and delete remaining unnecessary working copies, subject to the exceptions above and the capabilities of the relevant systems.

10. Security incidents

OSL maintains a practical process to receive, assess, contain, document, and respond to suspected unauthorized access, loss, or disclosure involving information in OSL’s possession or control. If OSL confirms an incident that affects Client Data, OSL will notify the affected client without unreasonable delay as required by the signed agreement and applicable law, provide reasonably available information about the nature and scope, take reasonable containment and remediation steps, and cooperate with the client’s response.

OSL is not responsible for incidents occurring solely in a client-controlled system unless caused by OSL’s breach of an applicable obligation. The client should immediately notify OSL if it believes OSL credentials, access, or delivered configuration may be involved in an incident.

11. Client responsibilities

• Provide only information reasonably necessary for the engagement and identify sensitive or regulated data before access is granted.

• Do not send Restricted Data or credentials and immediately notify OSL if such information is sent inadvertently.

• Confirm the client has authority, notices, consents, licenses, and legal bases needed for the data and systems it asks OSL to use.

• Maintain tenant security, user lifecycle, backups, retention, audit, data-loss-prevention, conditional-access, and compliance settings unless expressly included in the SOW.

• Review permissions, test results, workflow logic, notices, reports, and deliverables before production use.

• Revoke OSL access when it is no longer needed and identify a person authorized to approve access and changes.

12. No security or compliance certification

OSL may configure workflow features that support approvals, records, reminders, access boundaries, or reporting, but OSL does not perform a formal cybersecurity audit, certify a control environment, guarantee legal or regulatory compliance, or replace the client’s security, legal, privacy, compliance, or records-management functions unless a signed Statement of Work expressly states a qualified service.

13. Changes to this Policy

OSL may update this Policy as services, tools, practices, or law change. The current public version will show the last-updated date. A later public update does not retroactively change a signed client agreement. Material changes affecting an active engagement will be handled as required by that agreement.

14. Contact

Questions, data-return requests, or suspected incidents involving information provided to OSL may be sent to Ops Systems Lab LLC, Attn: Data Handling, 5195 Hampsted Village Center Way PMB 700, New Albany, OH 43054 USA, at privacy@opssystemslab.com. Website: https://opssystemslab.com