Compliance

Marketplace & Certification Readiness

Advanced

Selling through Microsoft AppSource, and meeting the certifications our customers expect, sets a clear bar we must build to. We must not rush to meet it at the end. Readiness is earned over time: secure architecture, evidence, privacy, accessibility, and tested operations, all in place and ready to show. Treat the certification checklist as a design input from day one.

Certification (AppSource publisher requirements, SOC 2 / ISO 27001-style controls, and the security baselines enterprise customers demand) is really an external audit of everything in these guidelines. You meet the bar by doing the work properly all along: authenticated and authorised endpoints, secrets in a vault, data in the right region, evidence trails, penetration testing, accessibility, and disaster recovery. You must also be able to show it on request.

The Finperiti audit made the cost of leaving this late very clear. The verdict was "AppSource NO-GO" with nine certification blockers: unauthenticated endpoints, forgeable webhooks, open CORS, secrets in config, wrong data region, unevidenced AI Act obligations, and end-of-life dependencies. We now have a guideline for every one of those. This topic is the standing checklist that keeps us over the bar at all times, instead of failing an assessment.

Build to the bar continuously

DoKnow the target requirements (AppSource publisher/security requirements and the certifications customers ask for) before building. Treat them as acceptance criteria, not a last-minute rush.
DoKeep the security fundamentals certifiable at all times: authenticated/authorised endpoints, vault-held secrets, encryption in transit and at rest, correct data residency, and least privilege.
DoProduce the evidence a reviewer will ask for as a by-product of normal work: audit trails, access reviews, scan results, pen-test reports, and DPIAs (see Auditability & Evidence, Compliance by Design).
DoCover the requirements that are easy to forget until they block you: accessibility (WCAG), data residency, privacy/DPIA, AI Act obligations, and a tested backup/DR plan.
ConsiderA living readiness checklist that maps each external requirement to the control that meets it and the evidence that proves it, kept up to date as the product changes.
AlwaysKeep independent verification current (penetration testing and security scanning), since certification requires it and it is how blockers are found before an assessor finds them (see Vulnerability Management).

Don't let blockers accumulate

DoFix certification blockers as ordinary engineering work, as they arise, instead of carrying a growing list towards a deadline.
DoRe-check readiness when something important changes. A new region, integration, data type, or AI component can bring back a blocker.
AvoidTreating certification as a one-off project that ends at the badge. Requirements and our system both change, and readiness lapses if it is not maintained.
NeverMisrepresent our security or compliance posture to a marketplace, assessor, or customer. Claim only controls we actually have and can evidence (see Professional Ethics & Integrity).

Self-review checklist

AskIf an AppSource/security assessment ran today, what would block us, and is each blocker tracked and owned?
AskCan I produce the evidence (audit trails, scans, pen-test, DPIA, access reviews) a reviewer would ask for?
AskAre the easy-to-forget requirements (accessibility, residency, DR, AI Act) actually covered?
AskDoes this change bring back a blocker we fixed before?

Why it matters: Certification and marketplace listing are gates to the customers and revenue the business is built on, and they fail on the exact issues these guidelines prevent. Building to the bar over time, and keeping the evidence, turns certification from a high-risk, last-minute project into a formality. It also means a customer's security questionnaire is something we can answer truthfully and at once.