Why open source document management for healthcare starts with ePHI on paper and scans
A self-hosted document system can meet the HIPAA Security Rule technical safeguards for scanned referrals, consent forms and administrative records, but only if access control, audit logging, encryption and backup are designed around it from the start. The platform itself does not make the deployment compliant. Organizations holding electronic protected health information (ePHI) in document form need to decide who owns each control before any scanner is connected.
The Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all ePHI they create, receive, maintain or transmit (45 CFR 164.302). That scope includes the scan queue, the import folder, OCR text and the backups, not only the final archive. *Paperless-ngx* and *Alfresco Community Edition* both need surrounding controls for these data: unique user identification, role-based permissions tied to the care team's need to know, logging that the audit controls in 45 CFR 164.312(b) can examine, and encryption in transit and at rest handled by the infrastructure around the application. Confirm with each vendor which encryption and audit features the release you plan to run actually provides, and document the gaps you close yourself. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not prevent HHS from later finding a violation (HHS FAQ 2003). Readiness is therefore shown through evidence: a risk analysis, the access matrix for each document class, audit log samples, tested restores and signed business associate contracts with the hosting and implementation partners. Ask your implementation partner to name the evidence it will produce during the engagement and who keeps it after handover.
Which HIPAA Security Rule requirements shape the document system build
This table maps the HIPAA Security Rule requirements most likely to change how a self-hosted document system is designed, configured and evidenced. Read each row as a design input: the requirement, where it sits in the rule, and what it means for the build. The main takeaway is that most of these controls sit outside Paperless-ngx itself, so they must be designed into the surrounding infrastructure.
| Requirement | Where it comes from | What it means for the build |
|---|---|---|
| Unique user identification | 45 CFR 164.312(a)(2)(i), a required implementation specification | Every clinician, clerk and service account needs its own login. Confirm that shared logins are not used for scanning stations or import folders, and that tags, correspondents and document types can restrict who sees referrals and consent forms. |
| Emergency access procedure | 45 CFR 164.312(a)(2)(ii), a required implementation specification | Document a break-glass route to retrieve records when the normal identity provider is down. Define who may use it, how use is logged and how access is reviewed afterward. |
| Automatic logoff | 45 CFR 164.312(a)(2)(iii), an addressable implementation specification | Set session timeouts in the web interface and any connected editor. Record the decision and the reason in the risk analysis, whether the setting is enabled or an alternative is used. |
| Audit controls | 45 CFR 164.312(b), a standard requiring mechanisms that record and examine activity in systems with ePHI | Paperless-ngx and the reverse proxy in front of it need logs for views, downloads, edits and deletions, forwarded to a central store. Confirm which events the platform records natively and which must come from the proxy, host or database. |
| Encryption and decryption | 45 CFR 164.312(a)(2)(iv), an addressable implementation specification | Paperless-ngx stores document files in clear text, so encryption at rest must come from the storage layer, volume or database. Document the key management model and who holds the keys. |
| Transmission security | 45 CFR 164.312(e)(1), a standard guarding ePHI sent over electronic networks | Scans, browser sessions, API calls and mail or folder ingestion all cross a network. Require TLS on every hop that carries ePHI and test that plain HTTP and unencrypted SMTP are blocked. |
| Business associate contract | 45 CFR 164.314(a)(2)(i), a required contract term for business associates | If a vendor or hosting provider can access ePHI, the contract must require Security Rule compliance, flow the same terms to subcontractors and require incident reporting. Confirm this with counsel before any hosted component is used. |
| Civil money penalty range | 45 CFR 102.3, adjusted for penalties assessed on or after 28 January 2026 | Penalties range from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294. Confirm the current figures on the eCFR page before using them in internal risk discussions. |
| Pending Security Rule revision | Proposed 6 January 2025 (90 FR 898), RIN 0945-AA22 | No final rule had been published as of October 2026, and the Unified Agenda projects final action for July 2027. Design for the current rule, and track whether the proposal would add requirements such as stronger encryption or asset inventories. |
Why Paperless-ngx needs encryption around its clear-text storage
Paperless-ngx does not, by itself, provide encryption at rest for the documents it stores, so ePHI protection for scanned referrals, consent forms and administrative records has to be built around the application. The document files, the thumbnails, the database holding metadata and the derived text all sit on the host's storage in forms the application does not encrypt on its own. Your protection therefore depends on the hosting environment: full-disk or volume encryption on the storage that holds the media directory and database, encryption or protected access for the database itself, encrypted backups, and a key management process that defines who can unlock volumes, where keys live and how they are rotated and recovered. Confirm the current storage behavior of the specific Paperless-ngx version you select with the project documentation and, more importantly, in your own test environment, by inspecting what lands on disk after a test scan is ingested.
The OCR text index deserves the same treatment as the scanned images. OCR output is a plain-text copy of the document, so a referral that is locked down as an image but indexed in clear text remains fully searchable by anyone with database or search-level access. Treat the derived text, the database rows that carry it and any search index or cache as ePHI in your data inventory, and include them in volume encryption, backup encryption and restore testing. Under the HIPAA Security Rule, encryption at rest is an addressable implementation specification in 45 CFR 164.312, which means it is not optional in the sense of being skippable without thought. You must assess whether it is reasonable and appropriate, implement it or implement an equivalent alternative, and document both the decision and the reasoning. Record which layer you encrypted, which key custodians you named, and what compensating controls, such as restricted host access and audit logging, you relied on if you chose a different path.
Which open-source platforms fit healthcare intake, records and secure exchange
No single open-source tool covers scanned referrals, formal records, file exchange, office editing and mail transport. Each platform below handles one part of the flow, and each has a limit that the design must absorb, especially where ePHI crosses a network or leaves the team that owns it.
Paperless-ngx for scanned intake
Paperless-ngx suits the front door of the workflow: scanned referrals, consent forms and insurance correspondence are OCR'd, tagged and filed into a searchable archive. Access is controlled through users, groups and object permissions, which maps to the unique user identification standard in the technical safeguards. The main limit is that Paperless-ngx does not encrypt stored files itself, so encryption at rest must come from the volume, the storage layer or a separate control. Ask the vendor and your implementation partner to confirm current permission and audit behavior before you design around it.
Alfresco Community Edition for formal records
Alfresco Community Edition fits administrative records that need a repository with defined content models, versioning and rule-based controls rather than a scan inbox. It is useful where records must be classified against a retention schedule before disposal. The limit is operational: the community edition's support, feature set and hardening responsibilities differ from commercial editions, so confirm what your organization must run and maintain itself, including patching and the audit configuration you need to evidence.
Nextcloud Server for controlled sharing
Nextcloud Server, licensed under AGPL-3.0 and at v33.0.10 published on October 15, 2026, lets clinical and administrative teams exchange documents with share permissions, expiry and access logging inside your own infrastructure. External sharing of ePHI is the risk point: external sharing of ePHI needs its own risk assessment covering recipients, link policy, transmission security and business associate terms before it is switched on. Confirm the audit and sharing features in your release with the vendor.
ONLYOFFICE Docs for administrative files
ONLYOFFICE Docs, licensed under AGPL-3.0 with v10.0.0 published on October 12, 2026, provides browser editing of Office Open XML documents such as policies, templates and staffing spreadsheets. It keeps editing inside the controlled environment rather than on local copies. The limit is integration scope: editing sessions pass document content through the editor service, so the connection to your file platform, its authentication and its logging must be designed and tested. It should not be the place where clinical record content is first created unless that design is validated.
mailcow or Stalwart for mail transport
mailcow (GPL-3.0, release 2026-09a published October 6, 2026) or Stalwart (AGPL-3.0, v0.16.26 published October 11, 2026) can carry the messages that move referrals and records between sites. Transmission security under the HIPAA Security Rule is not automatic: TLS enforcement, certificate management and the handling of messages containing ePHI must be configured and tested. Email is also a common path for misdirected PHI, so pair the mail platform with clear sending rules. Confirm TLS and logging features with each vendor.
How the deployment setting changes who hosts the ePHI
When a hospital or health system runs the document platform in its own data center, the covered entity is both the operator and the owner of the ePHI. No business associate contract is needed for the hosting itself, because the workforce of the covered entity is handling the data. The security program, the audit log review and the backup regime all sit inside one governance structure, which is simpler to evidence but leaves the organization carrying every technical safeguard directly. Any outside firm that installs, patches or troubleshoots the system is a business associate for the duration of that work, so its access terms must be documented.
- Hosting location: The covered entity controls racks, hypervisors, storage and backup media, and decides which network segments can reach the document service.
- Business associate contract: Not required for the in-house platform team. Any implementation partner or support vendor with access to ePHI needs a contract under 164.314(a)(2)(i) before work starts.
- Subcontractors: If the vendor uses its own subcontractors for remote support, those firms must be bound to the same Security Rule terms in writing.
- Administrator access: Hospital IT holds root and application administrator roles. Vendor administrator accounts should be named, time-limited and logged.
- Audit controls: The covered entity owns the audit log, its retention and its review under 164.312(b).
Check whether vendor remote sessions are recorded and whether the contract covers emergency access during an outage.
A clinic group that deploys the platform in a cloud account it controls keeps administrative authority but shifts physical hosting to the cloud provider. The cloud provider is a business associate in most cases, because it maintains or transmits ePHI on the group's behalf, so the group must confirm that the provider signs a business associate agreement that meets the Security Rule requirements. Responsibility for configuration, identity and encryption remains with the clinic group, and misconfiguration is the most common way this setup creates exposure.
- Hosting location: The clinic group selects the cloud region and account boundaries, and the provider runs the underlying facilities.
- Business associate contract: The clinic group signs with the cloud provider and with the implementation partner if that partner administers the account or touches ePHI.
- Subcontractors: Confirm which subprocessors the provider and the partner use and whether their terms reach ePHI. Ask for the list in writing.
- Administrator access: Cloud root and organization administrator roles should sit with named clinic staff, protected by multi-factor authentication, with break-glass accounts kept offline.
- Shared responsibility: The group owns object storage permissions, key management and backup copies, even when the provider supplies the infrastructure.
Confirm in writing which party manages encryption keys and whether the provider can access them.
A billing company, transcription service or scanning bureau that hosts the document system for several covered entities acts as a business associate. Each covered entity must have a contract that requires the business associate to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI and report security incidents, including breaches of unsecured PHI. Because one platform may serve many clients, tenant separation, per-client audit logs and clear administrator boundaries carry more weight than in a single-organization deployment.
- Hosting location: The business associate operates the platform in its own facility or cloud account, and each covered entity's documents must be logically separated from the others.
- Business associate contract: Each covered entity signs its own contract under 164.314(a)(2)(i). The business associate should not assume that one template covers every client.
- Subcontractors: Any hosting provider, OCR vendor or offshore support team that touches ePHI must accept the same terms in writing, and the business associate must report their incidents upward.
- Administrator access: Staff who administer the platform for several clients need role-based access, and client-facing views must not expose other clients' records. Access reviews should be documented per client.
- Incident reporting: Notification timelines and contacts should be defined in each contract so that the covered entity can meet its own obligations.
Ask for a current list of contracted subcontractors and a sample audit log export showing tenant separation.
How the document system connects to identity, mail, backup and the EHR
A self-hosted document system holding scanned referrals and consent forms touches five other systems, and each connection is a place where ePHI can leak or lose its audit trail. The cards below set out what each connection carries, what to decide before build, and what to test before go-live.
Identity and MFA for user access
Every person who opens a referral or consent form should sign in with a named account, so that unique user identification under the HIPAA Security Rule can be demonstrated. Map directory groups to document roles such as registration, clinician and billing, and remove shared logins from scanner and import accounts. External access is the highest-risk path: the CNIL fined Hopital Prive de la Loire EUR 500,000 in September 2026 partly because external access to its patient record system lacked VPN and multi-factor authentication. Confirm that remote users reach the system only through a controlled path with MFA.
EHR connection by reference only
Keep the document system separate from the electronic health record. Connect the two through defined exchanges, such as storing an index entry that links a scanned referral to a patient identifier and a document ID, rather than copying clinical notes into the archive. This limits the number of places ePHI is stored and keeps the EHR's own access rules as the controlling model for clinical content. Document the exact fields exchanged, the direction of each exchange, and who owns the mapping table.
Mail gateway for inbound referrals
Many referrals arrive by email with scanned attachments, so the mail path is an ePHI entry point. Require TLS for transport between sending servers, your mail gateway and the document system's ingestion mailbox, and reject plain-text delivery where the sender supports encryption. Restrict the ingestion mailbox to the import service account, and confirm how the gateway handles messages it cannot encrypt. The HIPAA Security Rule requires technical measures against unauthorized access to ePHI sent over electronic networks, so record how this path is configured and reviewed.
Audit log store and review
Audit controls under 45 CFR 164.312(b) require mechanisms that record and examine activity in systems holding ePHI. Send document views, downloads, permission changes and deletions to a log store that the document administrators cannot edit, and keep logs separate from the application database. Assign a named reviewer and a recurring review schedule, and confirm which events the platform records natively and which need a logging layer or export. Ask the implementation partner to show a sample review of an access event for a single patient record.
Encrypted, tested backups and restore
Backups copy every scanned referral and consent form, so they carry the same ePHI exposure as production. Encrypt backup sets with keys held outside the backup host, limit restore rights to named roles, and keep an offline or immutable copy. Paperless-ngx does not provide encryption at rest on its own, so confirm whether storage encryption sits at the volume, database or backup layer. Run a restore test on a schedule and record the result, because an untested backup is not evidence that patient documents can be recovered.
What auditors and HHS reviewers ask for and which component produces it
This table maps the evidence an assessor or HHS reviewer typically asks for to the part of a self-hosted document system that produces it. Use it to plan which records you must generate, export and retain yourself, since HIPAA has no certificate and the organization prepares this evidence. Confirm for each chosen platform which logs it produces and how they are exported.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Written risk analysis | Where ePHI enters, is stored, is transmitted and is backed up, with threats and the controls chosen for each | Your documented analysis, supported by a system inventory from the document platform, scanner workstations and mail ingestion path |
| Access roster with unique user IDs | Each person who can reach referrals or consent forms has a distinct account, with no shared logins | Platform user directory, ideally federated from your identity provider, exported with account owners and status |
| Role and need-to-know records | Which care or admin roles see which document types, and who approved that access | Group and permission configuration in the platform, plus your approval tickets and periodic access review sign-offs |
| Audit log extracts and review records (164.312(b)) | Who opened, changed, shared, deleted or exported ePHI and when, and evidence someone reviewed those entries | Application audit log, reverse proxy and host logs shipped to a central store, with a dated review record; confirm what the chosen platform logs natively |
| Transmission configuration evidence (164.312(e)(1)) | TLS settings for web access, scanner and mail ingestion, and any connections to storage or OCR services | Reverse proxy and mail server configuration, certificate inventory and scan results from your testing |
| Encryption configuration and key custody records | Where encryption at rest is applied, which keys exist, who holds them and how they rotate | Volume or storage encryption, key management system records, and access logs for key use; Paperless-ngx stores files in clear text, so this layer is yours to confirm |
| Backup and restore test results | Backups are complete, encrypted, separated from production and restorable within your stated objectives | Backup tool job reports, dated restore tests of document files and database, and checksum comparisons |
| Signed business associate contracts and subcontractor flow-down | Vendors that handle ePHI agreed to Security Rule terms, including downstream subcontractors and incident reporting (164.314(a)(2)(i)) | Contract file held by your legal or compliance team, with a list of hosting, support and implementation parties |
| Incident response records | How security incidents were detected, assessed, reported to the covered entity and remediated | Ticketing or helpdesk records, alert history from log monitoring, and post-incident reports |
How a healthcare rollout moves from risk analysis to a supervised go-live
This sequence moves a healthcare document system from a written scope of ePHI flows to a supervised production launch, with each phase producing evidence the security and compliance owners can review before the next phase begins. Scope, deliverables and timelines are agreed in writing before work starts.
Scope the ePHI flows and EHR boundary
Map every intake stream that brings scanned referrals, consent forms and administrative records into the document system, including fax gateways, scanners, email inboxes and shared folders. Mark where the document system stops and the EHR begins, and record which party is the covered entity and which are business associates. The output is a data inventory and a written scope that the client signs off before any build work starts. The step is closed when every data flow has an owner and a documented purpose.
Run the risk analysis and design controls
Work with the client's security and privacy officers to assess threats to the ePHI in each flow, then translate the findings into an access model, an audit design and encryption decisions. The access model covers unique user IDs, role-based permissions and emergency access. The audit design defines which events are logged, where logs are stored and who reviews them. Encryption decisions cover data at rest, which Paperless-ngx does not provide itself, and data in transit. The output is a signed control design that maps each decision to the relevant Security Rule standard in 45 CFR 164.312.
Build and harden in a non-production environment
Deploy the platform in a non-production environment inside the client's own infrastructure, using test ePHI or de-identified samples only. Configure permissions, logging, automatic logoff, encryption and backup according to the signed control design, then harden the operating system, containers and network paths. Test that unauthorized users cannot reach documents and that audit records capture the events the design requires. The output is a configured environment and a set of test records showing each control working as specified.
Pilot one intake stream and test restores
Run a pilot with a single intake stream, such as incoming referrals, using real workflows and the client's staff. Track classification accuracy, permission exceptions, audit log completeness and any manual steps that staff find unclear. Perform a full restore from backup into a separate environment and confirm that documents, metadata and access rules come back intact. The output is a pilot results report and a list of corrections, each assigned an owner and closed before the next stream is added.
Launch a supervised go-live with handover
Move to production with the client's operations and compliance teams present for the first intake cycles, with rollback steps ready and agreed in advance. Confirm the business associate contract terms are in place for any third party who touches ePHI, including support providers. Transfer administration to the client's team through working sessions and written runbooks. The output is a set of runbooks, an evidence binder mapping controls to artifacts, and a review schedule for access reviews, log reviews and restore tests. Ongoing support and upgrades are available as retainers.
What buyers ask before hiring a partner for healthcare document management
What drives the cost of a self-hosted healthcare document system?
The cost depends mostly on scope: how many intake streams feed the system, how much back-file scanning is involved, and how encryption, backup and identity integration are designed. Your organization pays for the infrastructure you run in your own cloud account or data center, for the implementation partner's fixed-scope work, and for any support or upgrade retainer. Infrastructure and storage grow with document volume, and the scanning of older paper records is usually a one-time project. Ask any partner for a quote that itemizes intake streams, back-file volume, encryption and backup design, identity integration, documentation and handover, and that separates one-time work from recurring support. Scope is confirmed in writing before work starts, so changes to these items should be handled through change control.
How long does a healthcare document management project take?
The timeline is set by the agreed scope, the results of a pilot, and how many change requests the project absorbs. Most engagements are fixed-scope, so deliverables and timelines are written down before work begins. A narrow pilot, such as incoming referrals routed through one intake channel, lets your privacy and security teams test access rules and audit logging before the design expands. Back-file scanning and classification of legacy records often take longer than the platform build itself, because they depend on paper volume and quality checks. Ask the partner to state the milestones, the pilot exit criteria, and how change requests will be priced and approved.
What does the work need from our own team?
The project needs named owners who can make decisions, not only attend meetings. Clinical leads should define which document types are in scope and who needs to see them. Privacy and compliance leads should approve retention rules, access rules and the handling of ePHI in test data. Security or infrastructure staff should provide access to the hosting environment, including network paths, identity directories and backup targets. Agree in writing on the rules for test data, including whether real patient records may be used at all, and who approves exceptions. Gaps in these decisions are the most common reason a project slips, so assign owners before the scope is signed.
Can a small healthcare team run a document system without a partner?
A small team can run a narrow intake use case, such as one clinic's referral inbox, if it has staff who can administer Linux, containers, backups and identity integration. The technical work is only part of the obligation. The HIPAA Security Rule at 45 CFR Part 164 Subpart C applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit, so you still need a documented risk analysis, risk management, policies, workforce training and written business associate contracts where a vendor handles ePHI. A business associate contract under 45 CFR 164.314(a)(2)(i) must require the vendor to comply with the Security Rule and to report security incidents. Confirm these obligations with your privacy officer and counsel before deciding who builds and operates the system.
Does open source software meet HIPAA requirements?
HIPAA does not regulate software licenses. The Security Rule applies to the processes and controls your organization uses to protect ePHI, whether the platform is open source or commercial. Open-source tools can support the required controls, including unique user identification, audit controls under 45 CFR 164.312(b), and transmission security under 45 CFR 164.312(e)(1), but you must configure, test and document them. Paperless-ngx stores files in clear text, so encryption at rest must be designed around it. There is no HIPAA certification: HHS states that no Security Rule standard requires certification, and private certifications do not prevent a later finding of violation. Enforcement by the HHS Office for Civil Rights is based on complaints, compliance reviews and audits. Civil money penalties for penalties assessed on or after 28 January 2026 range from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3).
How does a document management system stay separate from the EHR?
Keep the document system as its own application with its own access model, audit log and storage, and connect it to the EHR only through defined interfaces. The EHR remains the system of record for clinical data, while scanned referrals, consent forms and administrative records are captured, classified and retained in the document platform. Access should follow the need-to-know principle, so a user who can view a referral in the document system does not gain broader EHR access, and the reverse is also true. Integration points such as patient identifiers, document links and single sign-on should be documented and tested, with logs captured on both sides. Verify with your EHR vendor which integration methods are supported and whether the vendor's contract permits the connection.
What to ask an implementation partner before signing a healthcare scope
Start with the risk analysis, because every other control in the scope depends on it. Ask the partner how they will document the inputs to the risk analysis under 45 CFR 164.308 for this specific system: which ePHI enters through scanning and mail import, where it is stored, which people and service accounts touch it, and which threats they assessed. Ask who signs the document on each side, who owns the risk register after go-live, and how new scanned document types, such as referrals from a new clinic, trigger a review. A partner that cannot name the signatories before work starts is not ready to protect ePHI. Also ask whether they will map each control to the Security Rule standard it supports, and how they will keep that map current as the scope changes. Next, test access controls and audit logging with your own accounts, not the partner's demo ones. Ask how unique user identification will be enforced, with one account per person and no shared logins for the scanner or the import folder, and how roles in Paperless-ngx will be scoped by document type, such as referrals versus consent forms. Ask for the procedure behind the emergency access specification, the test they will run to prove it works, and whether break-glass use is logged and reviewed. For audit controls under 45 CFR 164.312(b), ask where Paperless-ngx activity is logged, how long logs are retained, who reviews them and how often, and how the partner keeps those logs unaltered, for example by shipping them to a separate write-once store. Request a sample log review report. Finally, ask how encryption at rest and in transit will be achieved, since Paperless-ngx does not provide encryption at rest itself. Ask which volume or database encryption they will use, where the keys live, who can create, rotate and revoke them, and how a lost key would be recovered. For transmission, ask how mail ingestion and file exchange are tested for TLS configuration and certificate validation, and how they handle business associate agreements under 45 CFR 164.314 for every subcontractor that can reach ePHI. Ask how backups are encrypted and restored, and how often a restore is tested. Ask what happens during upgrades and security releases, and what handover documentation you receive. Finally, ask the partner to show a sample evidence binder and a sample scope before you sign.
How DeployOpen scopes, builds and supports healthcare document management
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so healthcare document management stays under the organization's control. Engagements start with a written scope covering ePHI handling, access, audit logging and encryption before any build work begins.
How we scope
- Map which scanned referrals, consent forms and administrative records contain ePHI and where each category is stored.
- Define role-based access, unique user identification and the approval path for granting and removing access.
- Agree in writing how audit logs are captured, retained, reviewed and exported for examination.
How we build
- Deploy the chosen platform in the client's cloud account, data center or private network with documented configuration.
- Add encryption around storage and transport where the platform does not provide it, and test those controls.
- Test permissions, audit trails, backup restores and business associate-relevant integrations before go-live.
How we hand over
- Deliver architecture, configuration, access and backup runbooks written for the client's own administrators.
- Provide evidence packs that show how each technical safeguard is configured, for the client's auditors to review.
- Train the named administrators and confirm they can perform restores, access reviews and upgrades alone.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Review platform security updates and retest permissions and audit logging after each upgrade.
- Confirm with your compliance counsel which obligations apply to your organization and any business associates.
