Your alerts become incidents: build for Security Incident Response

• Your product raises alerts or detections: SIEM, EDR or XDR, email security or network security. ServiceNow’s own integrations, such as those for IBM QRadar and CrowdStrike, work this way.
• Or it acts on threats, blocking, isolating or looking something up, and customers want those actions inside their incident workflow.
• Your customers run Security Incident Response.
• A DLP tool feeds ServiceNow’s separate Data Loss Prevention Incident Response application instead, which has its own integration model rather than the security-incident capabilities described here. The documents and calendar on this page still apply to a Store app for it.
• Check first whether ServiceNow already ships an integration for your product.

• Customers need ServiceNow Security Incident Response, or Data Loss Prevention Incident Response for a DLP tool. In the customer’s instance, Application Manager can show your app as “Not Licensed”; ServiceNow lists “A required dependency is not licensed” among the possible causes.
• Tying incidents to affected assets relies on the customer’s own CMDB data.
• If your app is free, list it as type Integration: the Store says free apps of type Integration “are exempted from the custom table count and do not require custom table entitlement.” A free app of any other type uses each customer’s custom-table entitlement.

• Build Program membership, and vendor instances that can run the Security Operations plugins you need.
• ServiceNow’s Security Operations integration development guidelines, which say: “Any requirements for application certification or guidelines given in the Technology Partner Program literature supersede any information in this guide.”
• Sample alerts from your product, in the shapes and volumes customers really see.
• The response actions customers ask for most. Start there.

Certification reviews your documents as well as your app, and in our experience it’s the part most teams miss. ServiceNow’s certification guide says “Certification has two tracks”: an app review and a listing review.

• For the app review, ServiceNow asks for a “Design Document (for certification team only)”, a “Test Plan with results (for certification team only)” and an “Installation Guide (customer facing)”. Write the design document and test plan on ServiceNow’s templates; it provides a recommended template for the installation guide too.
• For the listing review, your Store listing “consists of marketing documentation, demo videos, and other resources”, and the team inspects it for “Accuracy” and “Adherence to branding guidelines”.

ServiceNow lists “How well you documented your architecture in your Design Documentation” among the things that decide how long certification takes. The calendar gives the documents a week of their own.

Plan on roughly 11–17 weeks (8–13 with a team that already knows the framework) from the start of design to a Store listing. The framework takes time to learn, and design is where that time goes.

Not in ServiceNow’s Build Program yet? Add admission first: in our experience it takes 2–6 weeks, because ServiceNow reviews each application.

Weeks for design, build, documents and any programme steps come from our own projects. The review range is ServiceNow’s: certification “typically requires 3-5 weeks”, and no service level is published.

• An incident for every alert. Group related alerts, so analysts get incidents, not noise.
• Response actions built as one-off scripts instead of as capabilities in ServiceNow’s framework, so customers’ workflows can’t call them.
• API credentials stored in properties or scripts instead of credential records.
• Missing ACLs on custom tables, and client-callable script includes without ACLs, both in ServiceNow’s ten most-failed checks.

• Maintenance is a release certification for each family release: retest on the new release and submit a revised test plan. ServiceNow’s Upgrade Policy says it “generally releases two new release families per year”. Any change to the app is a recertification, planned as new work. Retest when ServiceNow updates its Security Operations applications.
• Keep your actions in step with your product’s API.

• What alert data lands in their instance, and what flows back to your product.
• Which response actions the integration can take on its own, and which need an analyst to approve.
• Which service account it runs as. Expect them to reject admin; use a dedicated integration role.