How Long Does It Take to Get My App Security Certified?

A client once asked us how long it would take to get their app security certified before launch. They had six weeks. The product was a property trades platform where landlords, homeowners, and tenants could raise a job, upload a specification for works, and manage transactions with tradespeople through the app. It handled payments. It had geotagging. It touched financial data. Six weeks was not going to be enough, and the reason they were only asking now was that nobody had built certification into the original timeline at all.

App security certification is a foundational requirement. It is a structural constraint that shapes every decision before it.

That gap, between when teams start thinking about security certification and when they actually need it, is where projects get into trouble. The technical build might be finished. The design might be polished. But if the compliance and approval work has not been planned for, a launch date is really just a deadline for finding out how much is still left to do.

This article covers what security certification actually involves for an app, how long each part realistically takes, and where teams consistently underestimate the timeline. The answers vary by product type, but the pattern is consistent: the later certification enters the conversation, the more expensive it becomes to address.

What Security Certifications Does an App Actually Need?

The answer depends on what the app does and who it serves. A content app with no user accounts and no payments has a light certification burden. An app that handles financial transactions, personal health data, or access to sensitive systems has a significantly heavier one. Apps typically sit somewhere between those two points, and the exact requirements are not always obvious at the start of a project.

Regulatory Frameworks by Sector

Apps operating in healthcare need to consider data protection frameworks specific to health information, which in practice means understanding how personal health data is stored, transmitted, and accessed. Apps handling card payments need PCI DSS compliance, which covers how payment data flows through the system. Apps operating in the UK and EU must meet GDPR requirements regardless of sector. These are legal obligations.

Platform-Level Requirements

Beyond regulatory frameworks, both Apple and Google have their own security and privacy requirements that apps must meet before they can be distributed. These are separate from legal compliance. An app can be fully GDPR-compliant and still fail App Store review for reasons that have nothing to do with data protection law. Understanding that platform approval and regulatory compliance are two distinct processes, with different timelines and different gatekeepers, is the starting point for realistic planning.

Only 16% of surveyed app developers, according to Pye Tait Consulting, 2023, are aware of the UK Government's Code of Practice for app store operators and app developers. That figure alone explains why certification tends to arrive as a surprise rather than a plan.

How Long Each Certification Type Realistically Takes

The honest answer is that timelines vary considerably depending on how well-prepared a product is when it enters the process. A team that has documented its data flows, built with security in mind from the start, and engaged a specialist early can move through compliance assessment faster than one doing all of that retrospectively. But even under good conditions, these processes take time.

A security risk assessment for a typical single-framework product takes approximately 13.9 hours of hands-on practitioner work, according to Cynomi. That covers the assessment itself. The client-ready report adds roughly the same again, and each required policy document adds another comparable block of time. These figures stack quickly once you account for multiple frameworks.

The ongoing cost matters too. Running a small team's compliance programme is estimated at 200 to 400 staff hours per year, according to Coalfire. For most products, certification is a recurring operational commitment.

App Store Approval Is a Certification Process Too

Teams often treat App Store submission as the final step of a launch, something that happens after everything else is done. In practice it is a separate review process with its own criteria, its own timeline, and its own capacity to delay or derail a release. Apple reviews around 90% of submissions within 24 hours according to Apple's published data. That sounds fast, and for a standard app it often is. But that figure does not reflect what happens when a submission touches a sensitive category.

Payment apps, apps with financial features, apps that handle health data, and apps in regulated categories receive more scrutiny. Review times extend. Rejection rates are higher. And crucially, the reason for rejection can shift between submissions in ways that are difficult to predict or prepare for.

We worked on a currency exchange app that was built to full compliance. It was an in-person currency exchange product, not a speculative payments service. It met every stated requirement. Apple rejected it repeatedly. Each time we addressed the stated reason for rejection, Apple produced a new one. The product never launched. It later became apparent that the timing of those rejections coincided with Apple preparing to launch Apple Pay and related payment services. We believe the rejections were tied to that. The client had engaged lawyers to challenge the process and ultimately spent too much money pursuing approval before choosing to stop.

That experience is not typical, but it is not unique either. For any app in or near the payments space, App Store approval carries a business risk that standard timelines do not capture.

When Apple Keeps Changing the Rules

The currency exchange app rejection process illustrated something that is hard to plan for: a review process where the stated criteria change between rounds. When Apple raised concerns that the in-person currency exchange app could be used for money laundering, arms dealing, or criminal activity, we put a transaction limit of €150 on the product. That limit would, practically speaking, eliminate the concerns Apple had raised. Apple rejected the app again regardless. At that point the client had invested too much money in the process and decided to stop rather than continue.

The pattern, address the stated concern, receive a new rejection, address that concern, receive another, is not something a compliance checklist can prevent. It reflects a situation where the stated reasons for rejection are not the actual reasons. In our experience with that product, the rejections appeared to be commercially motivated rather than genuinely policy-driven. There is no straightforward remedy for that.

Before building any app in the payments, financial services, or currency space, research whether the app store gatekeepers have commercial interests that overlap with your product. That question belongs in discovery, not in the rejection queue.

What this means for timelines is that App Store approval for sensitive-category apps should not be treated as a 24 to 48 hour step. Teams building in these areas should build weeks, and in some cases months, of review and resubmission time into their plan. Legal costs for challenging rejections should be considered a real budget line, not a contingency.

Why Payment and Financial Compliance Takes Longer Than Developers Expect

Payment compliance is rarely just a technical problem. On the property trades platform we built, where landlords, tenants, and homeowners could raise a job and manage transactions with tradespeople, the initial plan was a straightforward payment-on-completion model using Stripe. That approach was simple and would have been relatively quick to implement. But the product needed contractors to have confidence that funds were available before they started work, which meant the payment model had to replicate escrow behaviour.

We evaluated third-party escrow services and found they posed significant legal problems for the client. The client consulted solicitors, who advised against using those services. We then pursued a delayed payout approach through Stripe Connect, confirmed compliance directly with Stripe, and the product was treated as a marketplace or gig economy app with Stripe handling the regulatory compliance. That process, from initial payment model to final compliant architecture, took considerably longer than a simple Stripe integration would have.

Stripe Connect and the Customisation Trade-Off

Using Stripe Connect introduced its own constraints. Different account types impose different rules. Express accounts require near-immediate payouts, which did not suit our need for delayed disbursement. Moving away from Stripe's default setup gave us the control we needed, but the further you move from the standard configuration, the more complex the payment flows become. The balance we had to find was between getting exactly what the product needed and retaining the compliance and handling benefits that come with Stripe's default payment architecture.

If your product needs delayed payouts, escrow-like behaviour, or split payments, verify your exact requirements directly with Stripe before committing to an account type. The wrong choice at setup can require a rebuild later.

Legal Advice Is Part of the Timeline

The solicitor consultation on the property trades platform was not a formality. It changed the technical direction of the product. That kind of legal input takes time to arrange, takes time to receive, and then requires the technical team to respond to what it finds. Build that loop into the timeline from the start, because discovering it halfway through a payment integration is expensive.

How Early Architecture Decisions Affect Certification Time

The decisions made in the first weeks of a build determine how much certification work is needed later, which is why app architecture design has a direct bearing on the compliance effort that follows. An app built with security as a design constraint from the start, where data flows are mapped early, permissions are justified, and third-party libraries are evaluated for security as well as functionality, moves through compliance assessment faster than one where those questions are addressed retrospectively.

On the performance coaching survey app we worked on, we used iOS's built-in libraries to generate QR codes entirely within the presenter's native app, so the codes were never stored externally. The QR code was only ever live and visible in the venue at the time of the presentation. Once the presenter marked a survey as finished, no further responses could be recorded. That architectural choice, made early, meant there was no external storage vulnerability to assess and no open-ended data collection to justify to a reviewer.

Contrast that with a retrospective approach. A team that builds first and audits later often finds that data is being stored in ways that were not planned, that permissions are broader than necessary, and that third-party libraries introduce risks that nobody evaluated at the time of inclusion. Only 52% of developers say they always consider security when evaluating a new third-party library, according to Veracode, compared with 67% who consider functionality. That gap shows up later in the certification process as additional remediation work.

Architecture decisions are also harder to change than code decisions. The property trades platform's payment architecture, for example, was not something we could adjust once the product was in testing. The account types, payout rules, and data flows were structural. Getting them right early avoided a rebuild. Getting them wrong would have meant one.

Where Teams Should Build Certification Into the Timeline

Certification planning belongs in discovery, alongside the product and technical decisions it shapes. The question of what compliance a product needs is an architectural input. Knowing that a product will need PCI DSS compliance changes how payment flows are designed. Knowing that an app will be reviewed by Apple as a financial services product changes what features are included in version one.

1. Identify applicable regulatory frameworks during discovery, before any technical architecture is decided.
2. Map data flows and permission requirements as part of the design process, not after it.
3. Evaluate payment providers against compliance requirements before choosing an integration approach.
4. Build App Store submission into the release plan as a separate phase with its own buffer, particularly for payment or health apps.
5. Plan for at least one rejection and resubmission cycle in sensitive categories.

Highly regulated sectors see development budgets increase by 30 to 50% due to compliance, security, and data protection requirements, according to GoodFirms. That increase is real whether it is planned for or not. The difference is whether the team absorbs it as a known cost or encounters it as a surprise.

Add a compliance review checkpoint at the end of the technical discovery phase. At that point the product is defined enough to assess its regulatory obligations, but early enough that those obligations can still shape the architecture.

What Happens When You Run Out of Road

When certification has not been planned for and a launch date is approaching, the options narrow quickly. The team can rush the compliance work and accept the risk of gaps. It can delay the launch and absorb the commercial cost of that. Or it can launch a reduced version of the product that sidesteps the features requiring the most compliance work, and add them later. None of these is comfortable, and all of them are more expensive than having planned properly.

The currency exchange product we worked on illustrates the hardest version of this. The product was built. The compliance work had been done. The problem was not a gap in the team's preparation, it was a review process that appeared to be blocking the product for reasons unrelated to the stated criteria. At that point, the available options were to keep resubmitting, to challenge legally, or to stop. The client chose to stop. The commercial cost of that decision was the entire development investment, plus the legal costs of the challenge.

That is an extreme case, but the structure of the problem is not unusual. A product that reaches the certification or approval stage with unresolved questions faces a binary choice: fix it now, under time pressure, or accept the consequences of not launching. The cost of non-compliance is nearly three times the cost of compliance, according to Globalscape. That ratio holds across sectors and product types. The money spent fixing compliance problems at the end of a build almost always exceeds what it would have cost to address them at the start.

Conclusion

Security certification is a set of overlapping processes, some regulatory, some platform-specific, some legal, and each with its own timeline, its own gatekeepers, and its own capacity to block a launch. The time it takes depends on what the product does, how it was built, and how early in the process those questions were taken seriously.

The property trades platform we built needed a specific payment architecture, legal sign-off on escrow services, and direct confirmation from Stripe that the delayed payout approach was compliant. That work shaped the technical build. The currency exchange app we worked on met every stated requirement and still never launched, because App Store approval turned out to be a commercial decision as much as a compliance one.

What both products have in common is that the certification questions were real, consequential, and deeply connected to how the products were built. Treating them as a phase that happens after the build is the single most consistent way teams extend their timelines and increase their costs.

If your product touches payments, health data, or any regulated category, the compliance planning should start before the first line of code is written. If it has not started yet, starting now is still better than starting after a rejection.

Let's talk about your app's certification timeline

Frequently Asked Questions