Trust & Security

Client Data Security

How PBW Professional Services protects confidential engagement information, client environments, and sensitive data throughout the consulting lifecycle.

Contents

PBW treats all client data, system configurations, architecture details, and engagement specifics as confidential by default. This commitment applies from the first discovery call through engagement close, and governs how we handle every piece of information we encounter. We are prepared to work under your NDA, MSA, or both — from day one if required.

1. Confidentiality-First Engagement Model

PBW does not require a separate confidentiality onboarding phase. All client-facing information — including system architecture, workflow designs, compliance rule configurations, integration specifications, vendor relationships, and operational details — is treated as confidential regardless of whether a formal NDA has been executed. Where a client NDA or data-processing agreement exists, PBW operates strictly within its stated scope.

PBW does not use client information for marketing, case studies, or reference purposes without explicit written consent. Client names, firm details, engagement scope, and operational information are never disclosed to prospective clients or third parties.

If you require a specific confidentiality term, right-of-deletion provision, or data-handling constraint, PBW will document those requirements in the engagement agreement before work begins.

2. Client Environment Access

During an engagement, PBW may require access to client systems — typically Bloomberg AIM administration, Charles River IMS configuration, reference data feeds, compliance rule engines, order-routing infrastructure, or development/testing environments.

Access model:

  • Credentials and access are client-provisioned. PBW does not create, own, or independently provision its own standing credentials on client systems.
  • Access is scoped to engagement scope. PBW requests access only to the systems, environments, and functions required for the specific work described in the statement of work.
  • No standing access post-engagement. PBW does not retain credentials, VPN connections, jump-box access, or API keys after an engagement closes. Client IT teams retain full control over when access is granted and when it is revoked.
  • VPN and jump-box access. Where client environments require VPN or bastion/jump-box access, PBW connects using client-provisioned credentials and routing. PBW does not establish persistent tunnel infrastructure.
  • Read-only access where possible. PBW requests read-only or limited-privilege access to production-adjacent environments wherever the engagement scope allows. Write access is requested only where required for active configuration or implementation work, and only within designated environments.

Access termination should be coordinated as part of the engagement close process. PBW will confirm credential return or destruction upon client request.

3. Secure File Exchange

Project artifacts — including requirements documents, architecture diagrams, configuration workbooks, test scripts, SOWs, meeting summaries, and deliverable files — are not shared through consumer-grade cloud services, public file shares, or unsecured portals.

Exchange channels:

  • Client-approved secure channels. PBW uses whatever secure exchange method the client specifies: managed file transfer, SFTP, encrypted email, client-provisioned SharePoint or equivalent, or secure document collaboration platforms.
  • PBW secure exchange. Where the client does not prescribe a channel, PBW provides files through a password-protected, access-logged portal or encrypted attachment. No file is posted to a public URL.
  • No third-party sharing. Client files and artifacts are not shared with subprocessors, partners, or third parties unless explicitly authorized by the client in writing.
  • Encrypted in transit. All file transfers use TLS encryption. PBW does not transmit client files over unencrypted channels.

If your organization has a preferred secure file exchange method, indicate it during engagement scoping — PBW will accommodate your existing infrastructure and protocols.

4. Database and Sample-Data Handling

During UAT, parallel-run phases, and system configuration work, PBW may work with sample data or data extracted from client systems. Data handling follows these principles:

  • No production data leaves the client environment. Unless explicitly authorized in writing by the client's authorized representative, no production data — including positions, orders, account information, counterparty data, compliance rules, or reference data — is exported, copied, or transmitted outside the client's environment.
  • Sample and synthetic data. Where test data is required for configuration validation or UAT, PBW uses anonymized, synthetic, or masked sample data. Any data extracted for testing purposes is treated as confidential and returned or destroyed when testing concludes.
  • Client-managed environments. Where PBW connects to a client-managed database or data environment, access is scoped and monitored under the client's access controls. PBW does not replicate client data to external storage without written authorization.
  • Data minimisation. PBW accesses only the data elements necessary to perform the specific work in scope. Broad data dumps are not requested or retained.

If your compliance, legal, or information-security team has specific constraints on data access — including data residency, processing location, or specific prohibited operations — communicate these during scoping and they will be documented in the engagement agreement.

5. Credential Management

Engagements may require access to sensitive credentials — system administration accounts, Bloomberg AIM user profiles, Charles River administrator roles, custodian feed credentials, API keys, database connections, or network access tokens.

PBW's credential policy:

  • Client-provisioned only. PBW does not create or self-provision credentials. All credentials are provided by the client or provisioned by client IT under client control.
  • Secure handling during engagement. Credentials are not transmitted via unsecured channels (unencrypted email, consumer messaging apps, or public file shares). Credentials shared with PBW are used solely for the purposes specified in the engagement scope.
  • Credentials are not retained post-engagement. At engagement close, PBW returns or destroys credentials as directed by the client. This includes system accounts, API keys, VPN credentials, jump-box access, and any other provisioned access.
  • Client-initiated revocation. Clients may revoke PBW access at any time during the engagement without notice. PBW will confirm revocation and cease using the revoked credential immediately.
  • No credential sharing. Credentials are not shared between engagements, client environments, or PBW personnel outside the engagement team.

Coordinate credential return as part of the engagement close checklist. PBW will provide written confirmation upon return or destruction.

6. Audit Trails and Access Logging

PBW maintains internal engagement logs that record key activities, access events, and work performed on client systems during the engagement. These logs support accountability, issue resolution, and client audit requests.

  • Engagement activity logs. PBW tracks engagement milestones, deliverables, access sessions, and communications. Logs are time-stamped and structured to support ad hoc retrieval.
  • Available for client review. Upon request — before, during, or after an engagement — PBW will provide access logs, engagement records, and activity summaries relevant to the client's systems. Clients may request this information at any time.
  • Client-native logging. PBW does not replace client-environment audit infrastructure. Client-side logs (Bloomberg AIM activity logs, Charles River audit trails, database access logs, network access logs) are owned and maintained by the client. PBW can assist with log interpretation or export during the engagement as requested.
  • Log retention. Engagement logs are retained for a minimum of 12 months post-engagement, or longer as required by the engagement agreement or applicable law.

If your organization requires a specific log format, export schedule, or SIEM integration, discuss requirements during scoping.

7. Data Retention and Deletion

PBW retains project artifacts, engagement records, and client information according to the following policy:

  • Project artifacts (requirements documents, configuration workbooks, test scripts, SOWs, meeting summaries). Retained for 24 months post-engagement. Available for client handoff during this period. Securely deleted at the end of the retention period unless the client requests earlier deletion.
  • Engagement correspondence and communications. Retained for 24 months post-engagement, or as required by the engagement agreement.
  • Credentials and access materials. Returned or destroyed at engagement close. No standing retention.
  • Client-provided data extracts and sample data. Returned or destroyed when no longer needed for the engagement, or at engagement close — whichever comes first.
  • Billing and payment records. Retained as required by applicable tax, accounting, and legal obligations (typically 7 years).

Immediate deletion on request. A client may request immediate deletion of their engagement records, artifacts, and communications at any time by contacting PBW at info@pbwps.com. PBW will confirm deletion in writing.

Secure deletion. PBW uses industry-standard secure deletion practices for electronic records. Deleted materials are not recoverable through standard methods.

8. NDA and MSA Readiness

PBW is experienced working under client-provided confidentiality agreements, data-processing agreements, and master services agreements. We are also prepared to provide our own standard terms where needed to accelerate engagement initiation.

  • Works under your NDA. If your organization has a standard NDA, mutual NDA, or data-processing addendum, provide it during engagement scoping. PBW will review and execute within the standard review process.
  • Works under your MSA. Where a client requires a master services agreement as a precondition to work, PBW will review the proposed terms and negotiate scope, liability, and IP provisions as appropriate. We typically propose our own standard MSA as an alternative if client terms are not practicable.
  • Standard PBW MSA available. PBW maintains a standard consulting agreement covering confidentiality, scope of work, intellectual property, fees, termination, liability, and indemnification. A copy can be provided during the proposal stage.
  • IP provisions. Engagement deliverables — configuration documentation, process designs, test scripts, implementation playbooks — are typically work-for-hire assigned to the client, unless otherwise specified in the engagement agreement. PBW retains the right to use general OMS implementation knowledge and non-client-specific techniques in future engagements.

To request a copy of PBW's standard MSA, or to submit your NDA or MSA for review, contact info@pbwps.com with the subject line "Agreement Review Request."

Questions about PBW's data-security practices? Have a compliance or legal review in progress? Contact us to discuss your requirements before engaging.