What Your CISO Needs to See Before Approving a Mobile App for Enterprise Use: 2026 Checklist

73% of enterprise mobile apps require at least one security remediation cycle before the CISO approves them for deployment. Apps built with a security checklist from the start require 40% less rework than apps where security is retrofitted. If you are getting ready for a CISO security review, this is the checklist your security team is about to run through.

Why 73% of apps fail the first CISO review

Most enterprise mobile apps are built by development teams whose primary brief is to ship working software that users like. Security controls are added during QA, during the security review, or after the first penetration test returns findings. The controls work, but they are added to an architecture that was not designed for them. The result is gaps, inconsistencies, and rework.

CISOs have consistent review criteria. The 12 items on their checklist do not change much from firm to firm or year to year. What changes is how many development teams received the checklist before they started building. Most did not.

The 40% rework reduction for apps built against a security checklist is not a technology effect. It is an information effect. Development teams that know what the CISO will check build for those requirements. Teams that do not know build what they build and then remediate.

If you are a CTO or VP Engineering preparing for a CISO review, the fastest path to approval is to compare your current app against this checklist before the review. Findings you identify and fix before submission do not become remediation cycles. They become items you can check off in the review itself.

The 12-item CISO security checklist

These are the controls enterprise CISOs check most consistently when reviewing a mobile app for deployment approval.

1. Data at rest encryption All sensitive data stored on the device must be encrypted. On iOS, this means using the Data Protection API with the appropriate protection class (typically NSFileProtectionComplete for sensitive data). On Android, this means storing sensitive data in the encrypted keystore or using Android Keystore for cryptographic keys. The CISO will ask: what is stored, where, and is it encrypted?

2. Data in transit encryption All network communications must use TLS 1.2 at minimum, with TLS 1.3 preferred for new builds. The CISO will ask for evidence that no plaintext communication occurs. Network traffic analysis during the penetration test will verify this.

3. Authentication requirements Authentication must meet your enterprise policy. For most enterprise apps, this means supporting SSO via your identity provider (Okta, Azure AD, Ping), enforcing multi-factor authentication for privileged actions, and meeting your password complexity requirements. The CISO will check that the app does not implement a parallel authentication system that bypasses enterprise identity controls.

4. Session management Sessions must expire after configurable idle periods. The default configuration should match your enterprise policy (commonly 15-30 minutes for regulated data, up to 8 hours for low-sensitivity applications). Session tokens must be invalidated server-side on logout - an intercepted session token must not work after the user logs out.

5. Certificate pinning The app must verify it is communicating with your specific server by comparing the server's certificate against a pinned value. Without this, a network attacker who can intercept traffic can present a valid certificate from a trusted authority. Certificate pinning prevents that attack. The CISO will ask whether pinning is implemented and how the pinned certificates are updated when certificates rotate.

6. Jailbreak and root detection The app must detect when it is running on a device where the operating system security restrictions have been removed. Detection must happen at startup and periodically during the session. Policy response (warn, restrict, or block) must match your written policy. The CISO will ask: what happens when a compromised device is detected?

7. Screenshot prevention Screens that display sensitive or regulated data must prevent screenshot capture. On Android: FLAG_SECURE. On iOS: content protection APIs and monitoring UIScreen.isCaptured. Coverage must extend to all routes to sensitive screens - deep links, push notification taps, share sheet previews. The CISO will ask whether screenshot prevention has been tested on all platforms.

8. Clipboard control Fields containing sensitive data - account numbers, personal identifiers, authorization codes - must not write to the system clipboard, or must clear clipboard content after a short interval. The CISO will ask which fields are protected and what the clipboard retention period is.

9. Background data access When the app moves to the background (user switches to another app), any sensitive data visible on screen must be replaced with a placeholder. This prevents the recent apps screen from showing sensitive content and prevents screenshot capture of backgrounded app state. The CISO will check this by switching away from the app and reviewing the app switcher.

10. Third-party SDK audit Every third-party library included in the app must be documented, reviewed against your data classification policy, and approved. The CISO will ask for a complete SDK list and documentation of what each SDK collects and where it sends data. SDKs that transmit data to external servers without disclosure or consent are findings.

11. Penetration test A penetration test by a qualified third party must be completed before deployment. The test must cover network traffic analysis, local storage examination, authentication bypass attempts, binary analysis, and API security. The CISO will ask for the report and the status of any findings. Critical and high findings must be remediated before deployment.

12. MDM compatibility The app must function correctly on devices enrolled in your MDM platform (Jamf, Intune, MobileIron, or equivalent). This includes honoring app configuration profiles, respecting MDM-enforced restrictions, and supporting remote wipe of app data. The CISO will ask whether the app has been tested on a managed device with your standard MDM policy profile applied.

Data protection controls

Items 1 and 2 on the checklist - encryption at rest and in transit - are the foundational controls. Most apps implement them, but the common failure mode is incomplete coverage.

For encryption at rest, the failure is usually in secondary storage locations. The main data models use the keychain correctly. But then there is a log file in the documents directory. A cached PDF in the temp folder. A configuration file written during setup. None of these were included in the original encryption requirements because no one mapped all the locations where the app writes data.

Before submission, have your development team produce a complete data storage inventory: every file, every database, every cache, every location where the app writes anything. Review each entry against your encryption requirements. This is the work that prevents the data-at-rest finding.

For encryption in transit, the failure is usually in edge cases: the analytics SDK that makes HTTP calls, the legacy endpoint that the app calls for backward compatibility, or the debug mode that disables certificate validation. Network traffic analysis during the penetration test will find all of these. Find them yourself first.

Authentication and session management

Items 3 and 4 - authentication and session management - are where enterprise apps most often have policy mismatches.

The most common authentication finding: the app implements its own username and password system parallel to the enterprise SSO. This happens when the app was built by a vendor who was not briefed on the enterprise identity requirements. The app works, but it bypasses the authentication governance controls your CISO relies on. Fixing this after the fact requires rebuilding the authentication layer.

For session management, the most common finding is session tokens that do not expire server-side. The app shows a logout button that clears the local session. But if someone intercepted the session token before logout, that token still works against your API. Server-side session invalidation on logout is the control that prevents this.

Device integrity and runtime controls

Items 5 through 9 - certificate pinning, jailbreak detection, screenshot prevention, clipboard control, and background data access - are the controls most often missing from apps built by teams without regulated industry experience.

These controls are not difficult to implement. They are consistently missing because they are not part of standard mobile development practices and because teams building consumer-facing apps do not need them. Enterprise development teams that regularly build for regulated industries include them by default. Teams that do not have that background need to be briefed explicitly.

For certificate pinning, the follow-on question your CISO will ask is about certificate rotation: what happens when your server's certificate expires and you replace it? Apps with hard-coded certificates must be updated and released every time a certificate rotates. Apps with a proper pinning update mechanism handle certificate rotation without a forced app update. Build the rotation mechanism in from the start.

Third-party risk and penetration testing

Items 10 and 11 - SDK audit and penetration testing - are the controls that require external inputs.

The SDK audit should happen before development starts, not after the app is built. Identifying a problematic SDK after it has been used throughout the app is an expensive retrofit. Reviewing SDKs before adoption means choosing compliant options and building the app correctly the first time.

The penetration test must be scheduled before development completes, with enough lead time to remediate findings before launch. A pen test scheduled for one week before the planned launch date leaves no time for remediation if critical findings are identified. Schedule the test for four to six weeks before planned launch.

How to present the checklist to your CISO

Before your CISO review, prepare a security evidence package covering each of the 12 items. For each item, the package should include: the control that is in place, how it was implemented, how it was tested, and any open items with a remediation timeline.

CISOs do not trust claims. They trust evidence. "Certificate pinning is implemented" is a claim. A network traffic capture showing the app refusing to connect when the certificate does not match is evidence. For each control, show the test result, not just the assertion.

The CISO is not looking to block your project. They are looking for evidence that you thought about security before shipping, not after. The security evidence package is the artifact that demonstrates that.

How Wednesday builds for CISO sign-off

For enterprise mobile engagements, we run a security requirements session with your security team before development starts. The output is a security specification that maps each of the 12 checklist items to the specific implementation your security team requires.

Development builds to that specification. Security controls are not reviewed in QA - they are built in from day one. When the CISO review arrives, the security evidence package is an output of the development process, not a document assembled under deadline pressure.

The 40% rework reduction is a predictable outcome when the security requirements are known before development begins. The information advantage drives the result.