Integration Architecture for Secure Enterprise File Sharing: Data Flows, DLP, and Encryption Across M365, iManage, Salesforce, and MFT

Enterprise file sharing doesn’t happen in isolation. The moment an organization connects a secure file sharing platform to Microsoft 365, a document management system, a CRM, or a managed file transfer channel, the security question shifts. It’s no longer just about what controls the core platform applies — it’s about whether those controls follow the data as it moves across integration boundaries.

That’s the integration architecture problem. And it’s a problem that procurement processes often underweight. Vendor capabilities lists will enumerate supported integrations by name. What they rarely answer — clearly, publicly, verifiably — is whether the same DLP policies, the same access controls, the same audit events, and the same encryption posture apply consistently to data that arrives from or departs through a third-party connector, versus data that moves through native platform functionality.

This post is for integration architects and security architects evaluating enterprise file sharing platforms. It maps data flows per integration pattern — Microsoft 365, iManage, Salesforce, and SFTP/MFT — and identifies the specific security controls that must apply across all of them. It also surfaces the one question that currently requires a direct conversation with Kiteworks rather than a documentation lookup: customer-side encryption key ownership for data that transits third-party connectors.

Executive Summary

Main idea: Integration security is not about whether a platform supports a particular connector — it’s about whether the platform’s policy engine governs data regardless of which connector triggered the operation. DLP classification, access control enforcement, audit logging, and encryption posture must apply with equal consistency to a file moved through a SharePoint connector, an iManage sync, a Salesforce attachment, or an SFTP transfer. Gaps at integration boundaries are where data sovereignty breaks down in practice.

Why you should care: NIS 2, DORA, and ISO 27001 all require that security controls extend across the full data-handling chain, including third-party integrations. If your vendor can’t show you a per-pattern data-flow brief — or if that brief doesn’t address encryption key ownership through the connector — that’s an evidentiary gap your auditors will eventually find.

5 Key Takeaways

1. Policy enforcement must follow data across every integration channel, not just the core platform. DLP rules, sensitivity labels, and access control policies that don’t apply consistently when data flows through an M365 connector or an SFTP channel create real security gaps — gaps that tend to become compliance findings at exactly the wrong moment.
2. Each integration pattern has a distinct data-flow architecture — and distinct risks. A SharePoint connector, an iManage sync, a Salesforce attachment handler, and a managed file transfer pipeline each touch data differently. Understanding the actual data path — where data lands, what transforms it, which system holds it at rest — is prerequisite to understanding the security posture of that integration.
3. Audit coverage is only meaningful if integration-triggered events appear in the same log substrate as native operations. A 632-event audit log that captures native file operations but silently omits events triggered by third-party connectors gives you partial forensic coverage. Partial coverage is not the same as coverage. Verify event completeness per integration channel, not just for the platform overall.
4. Encryption key ownership through third-party connectors is a question that requires a direct answer, not a documentation assumption. Customer-managed encryption (HYOK) is well-documented for native Kiteworks operations. Whether the same key ownership applies — technically and verifiably — to data that passes through an M365 connector or a Salesforce integration is not fully addressed in public documentation. Ask the question explicitly before committing to an architecture.
5. MFT/SFTP channels are not legacy infrastructure — they are active high-risk data paths that require the same policy governance as any other integration. Managed file transfer and SFTP channels move large volumes of structured data, often in batch, often without a human in the loop on each transfer. The policy engine must apply to these channels as rigorously as it does to interactive user sessions.

Why Integration Architecture Is a Sovereignty Question

A defensible sovereignty posture requires that you can trace exactly where data goes when it flows through an integration, which system holds it when, and which security controls apply at each point. That standard is reflected across NIS 2 Article 21, DORA’s ICT third-party risk requirements, and ISO 27001 supply chain security controls.

Most enterprise file sharing vendors publish integration capability lists. Far fewer publish per-pattern data-flow documentation showing, for example, whether DLP policies are evaluated before or after the file transits the connector, whether HYOK key ownership applies continuously throughout the connector pipeline, or whether the encryption key that protects the file at rest is the same key (under the same customer ownership) throughout the journey. Those architectural details are the substance of a sovereignty claim. Their absence is not a minor gap.

Kiteworks documents its integration capabilities extensively. The honest position is that per-pattern data-flow documentation consolidating these architectural details into a single publishable brief does not currently exist in the public domain. The capabilities described in this post are drawn from publicly available product documentation. Where critical questions remain unanswered publicly, they’re explicitly flagged.

Per-Pattern Data Flow: Four Integration Architectures

Understanding the security posture of an integration starts with understanding how data actually flows through it. The four patterns below — Microsoft 365, iManage, Salesforce, and SFTP/MFT — each have distinct architectures, distinct risk profiles, and distinct questions that security architects need to resolve before deploying them in sensitive data environments.

Microsoft 365: SharePoint, Teams, OneDrive, and Outlook

Microsoft 365 is the dominant integration pattern for most enterprise customers. The integration surface spans four distinct products — SharePoint document libraries, Teams file sharing, OneDrive sync, and Outlook mail — each of which moves data differently and raises different security questions.

What the integration does

The Kiteworks M365 integration allows users to access SharePoint, Teams, and OneDrive data from within the Kiteworks interface via the Repositories Gateway — Kiteworks’ native connector framework for third-party repositories — and to send and receive files using Outlook without leaving the native mail client. Kiteworks’ DLP policies, classification labels, and access controls apply to these operations through the platform’s policy engine, regardless of which M365 product surface triggered the action.

For email specifically, the Email Protection Gateway (EPG) and SMTP gateway integration extend Kiteworks’ policy enforcement to Outlook mail flows — applying content inspection, DLP rules, and encryption controls to outbound attachments and inbound file receipt, not just to files moved through the file sharing interface directly.

The data-flow question

When a user accesses a SharePoint file through the Kiteworks connector, two architectural questions matter. First: does the file remain in SharePoint storage (with Kiteworks acting as a policy and access control layer), or does it transit Kiteworks infrastructure? Second: if it transits Kiteworks infrastructure, does HYOK key ownership apply continuously throughout that transit path?

The public documentation establishes that Kiteworks applies its policy engine — DLP, classification, access controls — to M365 integration operations. It also establishes that Hold Your Own Key (HYOK) encryption is available for Kiteworks-managed data. What is not explicitly documented publicly is whether HYOK key ownership extends to data that moves through the M365 connector specifically, or whether that connector pathway operates under different encryption assumptions.

Questions to ask Kiteworks directly:

• For data accessed through the SharePoint connector: does the file transit Kiteworks infrastructure, and if so, under what encryption posture?
• Does HYOK key ownership apply to data processed through the M365 connector pipeline, or only to data stored natively in Kiteworks?
• At what point in the data flow does DLP policy evaluation occur — before or after the file transits any connector-specific processing?

iManage: Document Management Integration

iManage is the dominant document management system in legal and professional services environments. The iManage integration connects Kiteworks’ secure file sharing and transfer capabilities to iManage matters and workspaces — allowing data to be sent externally through Kiteworks while remaining governed by the matter and access control structure of iManage.

What the integration does

The integration allows users to share iManage documents through Kiteworks’ secure delivery channels without needing to export files to a separate location first. Kiteworks’ access controls — who can receive the file, under what terms, with what expiry — apply to the outbound transfer. The audit trail of the outbound operation is recorded in Kiteworks’ 632-event audit log.

For legal environments where matter confidentiality is a hard requirement and where regulatory frameworks like BSI C5 (relevant for German legal practices) or ISO 27001 add further audit expectations, the ability to log external file transfers in a certified audit infrastructure — rather than in ad hoc email records — is the core value of this integration.

The data-flow question

The key architectural question for iManage integration is whether data, when pulled from iManage for external delivery through Kiteworks, is held in Kiteworks storage transiently or immediately streamed to the recipient. If transiently stored: under what encryption posture, and for how long? If streamed: what guarantees apply to data in transit?

Kiteworks documents end-to-end encryption for data in transit across integrations generally. The specific transit behavior of data moved from iManage through Kiteworks for external delivery is an area where per-pattern documentation would provide clearer assurance than general platform statements. Direct verification with Kiteworks’ technical team is advisable for organizations with strict matter confidentiality requirements.

Salesforce: CRM-Integrated File Exchange

Salesforce integration addresses a common operational problem: sales teams and relationship managers need to send and receive sensitive documents — contracts, proposals, due diligence materials — in the context of CRM records, but the native Salesforce file-handling capability doesn’t meet the security requirements that regulated industries apply to sensitive data.

What the integration does

The Kiteworks Salesforce integration allows users to send files directly from within Salesforce records using Kiteworks’ secure delivery infrastructure. Recipients receive a secure link rather than a file attachment. The file is delivered through Kiteworks’ policy-controlled environment — DLP checks, link expiry, download limits, and access logging all apply. The Salesforce record can be updated with delivery status.

For industries with strict data classification requirements — financial services under DORA, healthcare under national data protection frameworks, legal under professional conduct rules — this integration pattern matters because it prevents sensitive files from being emailed as uncontrolled attachments simply because a salesperson is working in Salesforce rather than a dedicated file sharing interface.

The data-flow question

The critical question for Salesforce integration is whether DLP policy evaluation occurs at the point the file leaves Salesforce and enters the Kiteworks delivery pipeline — and whether that evaluation is applied consistently with DLP checks on files uploaded directly to Kiteworks. If there’s a different code path for Salesforce-originated transfers, there may be a policy enforcement gap that adversaries (or careless users) could exploit.

The public documentation position is that Kiteworks’ policy engine applies across integration channels. Verification that Salesforce-originated transfers specifically pass through the same DLP pipeline as native uploads — including content inspection, not just metadata classification — is worth confirming during a technical evaluation.

SFTP, AS2, and Managed File Transfer

SFTP, AS2, and FTPS channels are often treated as legacy infrastructure. They shouldn’t be. In financial services, supply chain, healthcare, and government contexts, managed file transfer (MFT) channels move large volumes of structured data — often in batch, often automatically, often without a human reviewing each transfer. The policy controls that apply to these channels matter as much as those applied to interactive user sessions, arguably more.

What the integration does

Kiteworks’ MFT capability provides SFTP, AS2, and FTPS protocol support alongside its REST API and web interface. Automated transfer jobs, batch file processing, and partner connectivity scenarios — common in healthcare EDI, financial settlement, and government data exchange — can be handled through these channels. The platform supports scheduled transfers, conditional routing, and protocol translation between MFT-standard formats.

The architecture here differs from the connector-based integrations above. SFTP and AS2 transfers are often fully automated, with no interactive user session. This means that audit log completeness for these channels is especially important: if a batch transfer job moves several thousand files and something goes wrong, the forensic record needs to be as complete as it would be for a human-initiated transfer.

The data-flow question

Several questions apply specifically to automated MFT channels. Kiteworks MFT Server integrates DLP, advanced threat protection (ATP), antivirus, and Content Disarm and Reconstruct (CDR) scans directly into transfer workflows — meaning DLP content inspection applies to automated MFT transfers as part of the workflow execution, not only to interactive sessions. This is a documented capability: DLP scanning is a built-in workflow node, not an optional post-transfer check. The question to confirm for high-throughput environments is whether DLP content inspection scales operationally to large-batch contexts in your specific deployment. Audit events for MFT-triggered operations are recorded in the same 632-event log substrate as other platform activity, through the consolidated unified log stream.

For organizations running high-volume automated MFT pipelines, the practical verification step is to confirm that DLP scan throughput meets the transfer volume requirements of the specific deployment — and to run a test batch to confirm that individual file-level events are recorded in the audit log, not just job-level summaries.

Cross-Integration Controls: What Must Apply Everywhere

Individual integration patterns have distinct data flows. But four controls must apply consistently across all of them, or the security model is incomplete. These are the controls that integration architects should verify per channel — not just for the platform overall.

DLP and Classification: Policy Enforcement Across All Channels

Data loss prevention is meaningless if it applies only when users interact with the core platform. The point of DLP in an integrated environment is that the policy follows the data regardless of which application triggered the operation. A file uploaded directly to Kiteworks and a file accessed through a SharePoint connector should both be subject to the same content inspection, the same classification label evaluation, and the same block/warn/audit outcome if a policy is triggered.

Kiteworks implements integration-aware DLP policies designed to apply across all integration channels. Microsoft Information Protection (MIP) sensitivity labels are recognized and enforced as part of the policy evaluation — meaning a file already classified by M365’s own labeling infrastructure doesn’t bypass Kiteworks’ DLP rules simply because it arrived through the M365 connector. Custom classification labels can be applied independently of MIP labels where organizations maintain separate classification taxonomies.

The control to verify: does DLP content inspection — not just metadata or label checking, but actual content inspection — apply when files arrive through each integration channel? For each of the four patterns above, ask the vendor to walk through the DLP evaluation sequence in their technical documentation or reference architecture materials.

Access Control: Consistent Enforcement Regardless of Entry Point

An access control model that governs native Kiteworks access but is bypassed when a user accesses data through a SharePoint connector is not an access control model — it’s a collection of well-intentioned settings with an exploitable gap. Every integration channel is a potential entry point, and the same role-based and attribute-based policies must apply at every one of them.

Kiteworks enforces access controls at the policy engine level, meaning controls are evaluated regardless of which interface or integration triggered the request. User roles, department attributes, data sensitivity labels, and contextual factors — including geolocation, device compliance, and time-based access windows — can all be factored into access decisions for integration-triggered operations, not just for native UI interactions.

For Salesforce and iManage integrations specifically, where the user’s identity is established in a third-party system before the Kiteworks integration is invoked, verify how identity federation works and whether the Kiteworks policy engine receives the attribute context it needs to make fully informed access decisions. If identity context is truncated during the integration handshake, the access control policy may be applied with less attribute information than it would have for a native session.

Audit Logging: Complete Event Coverage per Integration Channel

Kiteworks’ 632-event audit log is one of the platform’s most significant governance differentiators. That value is predicated on completeness — events triggered by integration operations appearing in the same log substrate as events triggered by native user activity. If connector-triggered operations generate partial event records, or if automated MFT transfers are recorded in a separate, less detailed log, the forensic completeness of the platform’s audit trail is compromised.

The 632-event scope is documented as covering integration-triggered operations. The practical verification is straightforward: for each integration channel in scope, request a sample event log from a test environment and confirm that file access events, DLP policy trigger events, and authentication events appear with the same attribute completeness as they do for native operations. For SIEM integration, confirm that connector-triggered events arrive in the same syslog feed and with the same real-time delivery characteristics.

Encryption: Key Ownership Across Integration Boundaries

This is the control where the honest answer is that public documentation does not fully resolve the question — and where direct verification is essential rather than optional.

Kiteworks supports Hold Your Own Key (HYOK) encryption, giving customers control over the encryption keys that protect their data at rest in the Kiteworks platform. For native Kiteworks storage, this is a meaningful sovereignty guarantee.

The open question is whether the HYOK guarantee extends continuously to data that transits integration connectors. When a file is accessed through the M365 SharePoint connector, processed through the Salesforce integration pipeline, or delivered via the iManage connector — does HYOK key ownership apply throughout? This is a technical architecture question to confirm with Kiteworks for your specific connector configuration.

This isn’t a failure of the product — it’s a documentation gap. The technical answer may well be that HYOK applies consistently across all integration paths. But until that’s stated explicitly in per-pattern architecture documentation, or confirmed directly by Kiteworks technical teams, it should be treated as an open question rather than an assumption. Organizations for whom HYOK is a hard requirement — particularly those subject to BSI C5’s customer-key requirements or implementing architectural sovereignty controls — should make this question a gate condition in their technical evaluation.

Implementation Checklist: Verifying Integration Security per Channel

This checklist is for integration architects conducting a technical evaluation. It covers what to verify and how — not just what the controls are.

Before You Start

• Map every integration channel in scope. Don’t evaluate only the channels you plan to use at launch — evaluate all channels available, because enabled-but-unused connectors are still attack surface.
• For each channel, identify the data classification of data that will flow through it. The verification questions below are most critical for channels handling sensitive or regulated data.
• Obtain Kiteworks’ current BSI C5 Type 2 attestation report, ISO 27001 certificate, and any relevant SOC 2 Type II report. These confirm third-party verification of security controls. They are a baseline, not a substitute for per-integration verification.

DLP Verification per Integration Channel

• Request written confirmation that DLP content inspection (not just metadata classification) applies to files arriving through each connector in scope: M365, iManage, Salesforce, SFTP/MFT.
• In a test environment, transfer a file that would trigger a DLP rule through each connector. Verify that the rule fires and that the event appears in the audit log with the expected attributes.
• For MIP sensitivity labels: transfer a file with a sensitivity label applied in M365 through the SharePoint connector. Verify that Kiteworks recognizes and enforces the label without requiring the user to re-classify the file.

Audit Log Verification per Integration Channel

• For each connector, perform a test transfer and retrieve the corresponding audit log entries. Confirm that event type, user identity, file identifier, timestamp, and outcome attributes are all present — not just a generic “transfer occurred” record.
• Verify that connector-triggered events appear in the same syslog feed to your SIEM, not in a separate or delayed channel.
• For automated MFT/SFTP transfers specifically: run a test batch transfer and confirm that individual file-level events are logged, not just job-level summaries.

Encryption and Key Ownership

• If HYOK is in scope: obtain written technical documentation from Kiteworks specifying whether HYOK applies to data processed through each connector type. Do not assume — ask explicitly.
• For each connector that involves data transiting Kiteworks infrastructure: ask whether HYOK key ownership applies continuously throughout the connector pipeline, and obtain written architectural confirmation for your specific connector configuration.
• Confirm that encryption key rotation procedures apply to integration-processed data under the same terms as natively stored data.

How Kiteworks Approaches Integration Security

Most enterprise file sharing platforms treat integrations as feature extensions — additional connection points that expand what users can do. Kiteworks’ design position is that integrations are policy-enforcement scope extensions: every connector is a point at which the platform’s policy engine must apply, not a bypass route around it.

That design intention is backed by independent validation. Kiteworks holds BSI C5 Type 2 attestation — the German Federal Office for Information Security’s cloud security catalogue, which is among the most rigorous cloud security attestation frameworks in operation in the EU. BSI C5 Type 2 attestation covers the scope defined in Kiteworks’ engagement with the certifying body — organisations should verify the current scope statement to confirm which integration channels fall within the attested boundary. ISO 27001 certification and SOC 2 Type II reports provide additional third-party verification. Cyber Essentials Plus covers the UK regulatory perimeter. IRAP PROTECTED certification applies to Australian government use cases. Kiteworks’ FedRAMP High In Process status — the most demanding impact level in the US federal authorization framework — signals a security maturity that regulated organizations outside the US have also treated as a meaningful benchmark.

The breadth of that certification portfolio matters in this context because it provides independent evidence that security controls apply across the platform’s scope. It does not, however, substitute for per-pattern data-flow documentation. The honest gap — one that Kiteworks’ documentation is better positioned to close than any certification can — is the absence of a consolidated published architecture brief that traces data flows for each integration pattern and explicitly addresses encryption key ownership through each connector. That documentation exists internally. Its public availability would materially advance the evidentiary basis for sovereignty-conscious procurement decisions.

Organizations evaluating Kiteworks for sensitive integration architectures should treat the questions in this post not as blockers, but as the specific technical verification items to resolve in a structured evaluation process. The capabilities are strong. The documentation of those capabilities at the per-integration-pattern level is where the next step of maturity lies.

Conclusion

Integration architecture is where security posture is won or lost in practice — and the organizations that build durable sovereignty over their data are the ones that verify per-pattern, per-channel, per-control, rather than accepting platform-level assurances as sufficient. As regulatory frameworks including DORA and NIS 2 increasingly demand documented data-flow architecture, the gap between general capability claims and published per-pattern documentation will close — and the platforms that close it proactively will define the standard that others follow.

Frequently Asked Questions