You sell threat intel: build for Threat Intelligence Security Center

• You publish indicators of compromise, or you answer lookups about domains, addresses, file hashes and URLs.
• Customers want your intelligence alongside their security incidents, not in a separate console.
• A plain TAXII, STIX, MISP, CSV, JSON or RSS feed that customers add themselves doesn’t carry what your product offers.

• Customers need Threat Intelligence Security Center for a TISC feed or enrichment app. 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. For customers who run Security Incident Response without TISC, lookups can plug into SIR’s Threat Lookup and Enrich Observable capabilities instead: see the Security Incident Response plan.
• 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 Threat Intelligence Security Center.
• Which enrichment capabilities TISC supports for your kind of data. ServiceNow’s docs name specific vendors for some of them, so confirm yours can plug in before you design.
• Sample data at real volume: a full feed, and lookups for every observable type you support.

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.

• Duplicate indicators. Match what’s already in the customer’s library before you add to it.
• Lookups that fire faster than your API allows. Handle concurrency and rate limits.
• API credentials stored in properties or scripts instead of credential records.
• Large feeds imported without batching; performance is one of the review areas.

• 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 Threat Intelligence Security Center.
• Keep your STIX mapping current as your own data model changes.

• What their instance sends you in a lookup, since observables can reveal what they’re investigating.
• Where your intelligence comes from, and how you score confidence.
• Which service account it runs as, and what it can touch.