Budgeting for the AppExchange Security Review

The email came on a Thursday afternoon. Seventeen findings. One of them was a sharing model violation I had introduced nine weeks earlier, in a sprint that had nothing to do with the feature we were trying to ship. The launch date I had promised our first design partner was already three weeks behind us.

I thought that was the hard lesson. I was wrong.

When I resubmitted after remediation, the review came back with three new findings in code I had not touched. Between my original submission and the resubmission, the platform had updated its scanner version. Checks that had passed the first time failed under the new version. The fixes were not complicated, but the calendar moved again, and another external commitment slipped.

The third surprise came after we were listed. Not from releasing a new version. The listing came back into review on an annual cycle, independent of anything we shipped. The scanner baseline had moved. Some of what the review had approved the first time was being evaluated against a higher standard.

By the time I understood all three of those patterns, I also understood that I had been thinking about the security review entirely the wrong way.

The Clock Starts Earlier Than You Think

The AppExchange Security Review is not a formality. The marketplace takes it seriously because the security of every org that installs a package depends on what that review catches. That is the correct call. But the consequence for partners who treat the review as a box to check at the end of development is almost always a bruising surprise.

The initial review cycle takes weeks, not days. The exact length depends on your submission's complexity, your security posture, and how many findings come back on the first pass. If you submit and get findings, you fix them and resubmit. Each resubmission restarts the clock on that portion of the review. Multiple rounds of back-and-forth can consume two months before approval.

The math is simple but brutal: a team that submits once with clean findings ships in one review cycle. A team that submits with twenty findings, fixes them, resubmits, and picks up a few more ships in three or four cycles. Same feature set. Very different timelines.

This is what the timeline conversation is actually about. It is not really about how long the review process takes. It is about how many cycles you hand them.

There is a second clock most teams forget: the one that starts the moment you commit to a launch date. Every week in remediation is a week your design partners are waiting, your sales pipeline is stalling, and your engineering team is firefighting instead of building. The review does not exist in a vacuum. It sits in the middle of all your other commitments.

The partners who plan well treat the review as a fixed cost on the timeline, the same way they treat QA or infrastructure provisioning. They do not schedule it for the end. They build backwards from the review window to set the development cutoff.

What Triggers a Re-Review, and Why Your Roadmap Depends on Knowing

Once you are listed, the security review does not disappear. It comes back in at least three ways, and most ISV roadmaps account for none of them.

The first way is change-triggered. A new review is required when certain kinds of changes go into a managed package version. Changes to your permission model almost always trigger a full review. If a new version requests new object permissions, new field access, or elevated system privileges, plan for a complete review cycle. New external integrations or callouts to endpoints that were not in your original submission typically trigger review as well. Significant architectural shifts draw scrutiny even when they are not formally required to. If you are uncertain whether a planned change is a trigger, submit early and find out. The cost of discovering a trigger after you have already announced a GA date is far higher than the cost of asking the question two sprints ahead of time.

The second way is time-triggered. Existing listings are subject to periodic review on the platform's schedule, not yours. The scanner baseline moves over time. What passed when you were first approved may be evaluated against current standards the next time a review cycle touches your listing. Planning for this means maintaining a compliance posture after listing, not only during submission. Annual reviews belong on the roadmap as a fixed calendar event, the same way recurring infrastructure maintenance does.

The third way is scanner-version reclassification, and it is the one that hit me hardest mid-cycle. When the platform ships an updated scanner version, the criteria can shift. Findings that passed in a previous round can fail under the new version, even in code that has not changed. This is not a defect in the process; it reflects a genuinely evolving set of security standards. But for teams who are mid-review, it can extend the timeline through no fault of their most recent changes.

The strategic implication is straightforward. Every significant feature on your roadmap needs a security-review timeline baked in before that release gets a public commitment. And your post-listing roadmap needs to account for annual reviews and scanner-version updates the same way it accounts for new releases.

Why CI/CD Changes the Math

The teams that move through review faster are not writing perfect code on the first attempt. What they have in common is that by the time they submit, they have been running security analysis against their builds for months.

The platform offers a CLI-based static analysis tool that partners can run locally and in automated pipelines. This is a distinct instrument from the portal-submitted scanner the formal review uses; the underlying criteria overlap significantly, but the results are not guaranteed to be identical. The concrete shift is integrating this CLI analysis into your build pipeline as a merge condition, running it against every merge rather than treating a pre-submission scan as the primary safety net.

A finding caught during a sprint costs a few hours to address. The same finding caught during formal review costs weeks of calendar time and team morale. A criteria update in the CLI tool that happens while you are mid-development shows up in your pipeline immediately, giving you advance notice of potential gaps before you commit to a review window. The practice is specific: add the CLI analysis to your CI configuration, set a threshold for acceptable findings, fail the build when that threshold is crossed, and treat new findings the same way you treat failing tests.

The shift this requires is cultural more than technical. The analysis cannot live at the end of the pipeline as a pre-submission gate. It has to live in the middle, as a condition of merging. Once that norm is in place, the formal review stops feeling like a gamble. It becomes a confirmation of what you already know about your package, because potential gaps have been tracked continuously rather than inspected at a single point in time.

Budget for the Review Like Any Other Real Cost

The reason ISV timelines blow up at the security review is almost always that partners did not budget for it the way they budget for development work.

I did not. My first review cost six weeks I had not allocated. My second cost another two weeks because a scanner update moved the target between rounds. My third was an annual review I had not put on the roadmap at all. By the time those three lessons landed, the cumulative cost was one missed design partner commitment, two slipped sales conversations, and an engineering team that had learned to dread the review rather than treat it as a normal part of shipping.

The turn came when I stopped asking how long the review would take and started asking how many findings we would hand them. That single reframe changed how we planned every release afterward. The first decision was to add the CLI-based static analysis to every sprint's definition of done, the same way a failing test blocks a merge. The second was to write the review window into every roadmap before any external commitment went out the door. The third was to put the annual review date on the release calendar next to major version cuts, treating it as recurring maintenance rather than a surprise.

The next submission we ran through that discipline came back clean on the first pass. Not because the code was flawless, but because the findings had already been found and fixed in development, weeks before anyone hit submit. The review confirmed what the pipeline already knew.

That is the payoff. Not a clever workaround, and not a secret about how the review works. The teams that move through review quickly submitted something that was already compliant when they hit send. That outcome is the result of decisions made months before submission, and a roadmap that included the review as a recurring line item rather than a one-time gate.

Build compliant. Submit compliant. Plan for the review to come back.