- Home
- Services ▼
ServiceNow View all ServiceNow services →Other ServicesNot sure where to start? Talk to an expert →
- Industries ▼
- Resources ▼
- Company ▼
- Contact
Most first submissions come back. Not because the application is bad, but because it was written to work rather than written to pass review — and those are different standards. Ramisun reviews your application against the criteria reviewers actually apply, remediates what they will find, and prepares the documentation in the form they expect, so review becomes a confirmation rather than a rejection cycle.
Certification and security review is ServiceNow's assessment process for applications being published to the Store or deployed into sensitive customer environments. Reviewers examine access control, injection protection, data handling, third-party dependencies, upgrade safety, and structural conformance against published standards. Ramisun runs the same assessment ahead of submission, remediates what would be found, and prepares the documentation set reviewers expect — converting an unpredictable rejection cycle into a planned piece of work.
"An application that works and an application that passes review are different standards. Most teams only discover the second one after their first rejection."
The full application assessed against real review criteria before submitting.
Access control, injection, and data exposure issues fixed, not just listed.
The artefacts reviewers expect, produced in the form they expect them.
Findings triaged and answered so your engineers stay on product.
The findings are predictable, which is exactly why they are preventable.
Figures shown are industry benchmarks and illustrative placeholders — replace with sourced, dated statistics before publication.
Find what reviewers would find, before they do.
Automated analysis and Instance Scan across the application
Manual code review against real security review criteria
Findings ranked by likelihood of rejection and effort to fix
Issues fixed and verified, not merely documented
Submission artefacts prepared in the expected form
Package submitted and review responses managed through to outcome
Same reviewer, very different experience.
| Area | ❌ Typical Approach | ✅ Ramisun Approach |
|---|---|---|
| Code Review | None, or a quick internal skim | Full manual review against real criteria |
| Vulnerabilities | Discovered by the reviewer | Found and fixed before submission |
| Access Control | Assumed adequate | ACL model verified record by record |
| Credentials | Sometimes still in the code | Verified absent from code, update sets, and logs |
| Dependencies | Third-party libraries unexamined | Reviewed for licence and vulnerability exposure |
| Documentation | Assembled hurriedly at submission | Prepared to the expected structure in advance |
| Outcome | Rejection cycles with unpredictable timing | Review as confirmation, remaining findings minor |
Each capability maps to real delivery work — with outcomes and the Ramisun approach.
We read the whole application against the criteria reviewers apply, not a sample. Automated scanning catches the obvious; manual review catches the access-control and data-handling issues that scanners routinely miss.
Access control is the most common source of review findings and the least reliably caught by tooling. We verify the ACL model record by record against least-privilege expectations rather than trusting that it was designed correctly.
A findings report you have to act on yourself is half a service. We fix what we find, verify the fix, and re-review the affected area so remediation does not introduce its own problems.
Bundled libraries carry both licence and vulnerability exposure, and both are reviewable. We check what your application ships with before a reviewer does.
Reviewers work from documentation, and a package that is hard to review takes longer and attracts more questions. We prepare the artefacts in the structure reviewers expect.
Once submitted, the review generates questions and sometimes findings. We handle that exchange so your engineering team is not repeatedly pulled off the product to answer them.
Predictable preparation instead of an unpredictable rejection cycle.
We apply the same criteria a reviewer will, ahead of submission. Findings are far cheaper to fix on your own schedule than under the pressure of a rejection.
A findings list you have to act on alone is half the job. We remediate, verify the fix, and re-review the affected area so remediation does not introduce new issues.
Automated tools miss most access-control and data-handling problems, which are exactly the findings that cause rejections. Full manual review is the core of the service.
We manage the submission and the reviewer exchange. Certification should not consume the capacity you need for your roadmap.
ServiceNow's review runs on their schedule. We scope our preparation work precisely and are explicit that the review period itself is outside any partner's control.
Review requirements change between releases. We confirm current criteria with ServiceNow at the start of each engagement rather than working from last year's checklist.
Let us find what the reviewers would find, first. You will get a ranked findings list with effort estimates before committing to remediation.
"An application that works and an application that passes review are different standards."
Broadly: access control and ACL coverage, injection and input validation, credential handling, data storage and exposure, third-party dependencies, upgrade safety, and structural conformance to scoped application requirements. The precise criteria evolve between releases, so we verify the current standard with ServiceNow at the start of every engagement.
Because applications are typically written to work rather than written to pass review, and those are different standards. The most common findings are access control gaps, hardcoded credentials, and insufficient input validation — all preventable, and all much cheaper to fix before submission than under the time pressure of a rejection.
Yes, and it is a common starting point. We work from the findings you received, address each one properly rather than minimally, and then review the rest of the application — because a rejection on three findings often means there are others the reviewer did not reach.
We fix them. A findings report you then have to act on yourself is half a service. We remediate, verify each fix, and re-review the affected area, because remediation done hastily is a common source of new problems.
Typically 4–8 weeks depending on application size and starting state, covering review, remediation, and documentation. ServiceNow's own review period follows and runs on their schedule, which we scope separately and do not promise dates for.
It is required for Store publishing, but the same standards are worth meeting for any application deployed into a regulated or security-conscious customer environment. Many enterprise customers apply comparable scrutiny to applications installed directly on their instance.
Every quarter without the right platform is revenue and efficiency left on the table. Tell us your challenge — get a real plan back, not a sales script.
A ServiceNow consultant will reach out within one business day to schedule your session.