DLP Data Loss Prevention policies in mobile app

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.
Development and support of all types of mobile applications:
Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1 servicesAll 1735 services
DLP Data Loss Prevention policies in mobile app
Complex
~3-5 business days
FAQ
Our competencies:
Development stages
Latest works
  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    756
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    624
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1054
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    947
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    862
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    445

Implementing DLP (Data Loss Prevention) Policies in Mobile Apps

DLP in mobile context is not antivirus or a firewall. It's a set of restrictions on what a user can do with corporate data: copy to clipboard, take a screenshot, forward to a personal messenger, upload to a personal cloud drive. Without these restrictions, MDM loses its purpose.

Where Data Actually Leaks

Clipboard — the most common leak point. A user copies a corporate contract, switches to WhatsApp and pastes it there. On Android, intercept the copy moment via ClipboardManager.OnPrimaryClipChangedListener and clear the buffer when the app goes to background:

class DlpClipboardWatcher(private val context: Context) {

    private val clipboard = context.getSystemService(ClipboardManager::class.java)

    fun onAppBackground() {
        // Clear buffer if it contains corporate content
        val clip = clipboard.primaryClip ?: return
        val text = clip.getItemAt(0)?.text?.toString() ?: return

        if (dlpClassifier.isCorporateContent(text)) {
            clipboard.clearPrimaryClip()
        }
    }
}

On iOS 16+, the app receives UIPasteboard.changedNotification, but it can't read other apps' clipboard — only its own. However, you can prevent pasting into your fields via custom UITextView with overridden canPerformAction(_:withSender:).

Screenshots. On Android block via WindowManager.LayoutParams.FLAG_SECURE:

// In Activity or Fragment
window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)

This flag also hides content in Recent Apps switcher — important for sensitive screens. Don't apply globally: users complain they can't screenshot instructions. Enable only on screens with sensitive data.

On iOS there's no native screenshot ban. You can catch the event:

NotificationCenter.default.addObserver(
    self,
    selector: #selector(screenshotTaken),
    name: UIApplication.userDidTakeScreenshotNotification,
    object: nil
)

And in response — blur the screen, exit the mode, log the incident. But not prevent it.

Screen recording and screen mirroring — separate story. On iOS UIScreen.isCaptured lets you detect recording via AirPlay or ReplayKit and replace content with a placeholder.

Open-In and Share Sheet

The most painful point — UIDocumentInteractionController on iOS and Intent.ACTION_SEND on Android. By default, the user can open a corporate PDF in any third-party app.

On iOS, restriction goes through UIActivityViewController with custom excludedActivityTypes — but the list must be maintained manually, and new apps don't appear automatically. The correct corporate approach is Managed Open-In via MDM profile: documents from managed apps open only in other managed apps.

On Android — via DevicePolicyManager with Work Profile. Intents from the work profile by default don't go to personal. This is default behavior, don't break it — just don't break it accidentally via addCrossProfileIntentFilter.

Data Classification

DLP without classification — restrictions everywhere and always, which frustrates users. Need to differentiate:

Data Type Level Restrictions
Public materials Public None
Internal documents Internal Clipboard only between corp apps
Customer personal data Confidential FLAG_SECURE + no Open-In
Financial data Restricted All restrictions + watermark

The classifier can be simple — regex on patterns (contract number, INN, IBAN) — or ML-based via CoreML / TensorFlow Lite for complex cases.

Watermark on Documents

For Restricted level, add dynamic watermark with username and timestamp when displaying documents. This doesn't prevent screenshot leaks, but creates an audit trail. Implemented via custom PDFRenderer on Android or PDFKit on iOS with overlay via Core Graphics.

Logging DLP Incidents

Every DLP event goes to SIEM: screenshot attempt on protected screen, open-in attempt to unapproved app, clipboard wipe. Logs stored on server, not on device.

Work Stages

Audit existing app for leak points → design policies and classification matrix → implement technical restrictions → test via pentest scenarios (screenshot, ADB backup, clipboard) → documentation for IT.

Timeline: 3–5 days for basic set (screenshots, clipboard, open-in). With ML classifier and watermark — from 1.5 weeks.