This application integration checklist tests one link between two applications through 16 checks, scored out of 32, before go-live and again after each change. A link here means one application passes records to another without anyone retyping them. Treat it as your own review of the link: it gives no audit result, certificate or legal advice, and it follows Signisys’ own method.
Last reviewed 2026-11-05 by Manish Sharma.
Application Integration Checklist: Four Groups of Four Checks
Sixteen checks sit in four groups, and every check asks you to show a record. The list suits a leader in IT, operations or the business, in an Indian or GCC firm, with a link built or nearly built, perhaps while connecting your business systems. It also works on a link that already runs, and one link gets one score.
| Group | Question it asks | Checks |
|---|---|---|
| Owners and Hand-Overs | Does a named person stand behind each side, and does the link replace a real manual step? | 1 to 4 |
| Access and Incoming Records | Does the link act under its own sign-in, and does it distrust what arrives? | 5 to 8 |
| Failure and Proof | Does a failed record reach a fix, and do tests show the link works? | 9 to 12 |
| Watching, Changing and Leaving | Does a silent stop reach a person, and is there a way to change and to exit? | 13 to 16 |
An integration readiness checklist earns its keep when someone other than the builder marks it. Paste the tables into a sheet, then add three columns of your own: who marked, when, and the score.
Marks: Ready, Partly Ready or Not Ready
Each check scores 2 for Ready, 1 for Partly ready or 0 for Not ready, so 16 checks give a maximum of 32. The marks and the rules below are Signisys suggestions, so adjust them to your own link.
- Ready (2): you can open the record now, and it carries a date after the last change to the link.
- Partly ready (1): the record covers part of the link, or the team only believes it exists.
- Not ready (0): no record exists, or nobody has tried the test.
A record that nobody can open scores no more than 1, whatever the team believes. The date matters because a record from before the last change may describe a link that no longer exists.
If a check asks for a sample, take three records from last month’s busiest day, then write down their references. When a check does not apply, take 2 off the maximum and say so beside the total. For example, check 10 does not apply to a link that only reads. That link has a maximum of 30.
Illustration, not a client: the link’s credential sits with a named person in a secrets store, but a copy remains in a shared document. Check 7 asks for none in shared documents, so it scores 1 and not 2.
This list sets no target total. Instead, the number to watch is how many Not ready marks each group holds.
Key Takeaway A mark of 2 needs a record dated after the last change to the link.
Application Integration Checklist: Owners and Hand-Overs (Checks 1 to 4)
These four checks show who answers for the link and what it replaces. A link with no owner on one side has nobody to turn to when something changes.
| Check | Record to open | Ready when |
|---|---|---|
| 1. Both applications and their owners have names. | A short list of the two applications, each owner and the business sponsor. | Each owner confirms their line in writing before the sponsor signs. |
| 2. Every record crossing the link has a trigger and a busiest-day volume. | Crossing notes, one line per record type. | Someone outside IT can name the manual step that each crossing replaces when asked. |
| 3. Someone chose how to build the link, and the reason is on paper. | A dated decision note. | The note holds the reason and the names of the people who decided. |
| 4. Other applications that read the same records have a list. | The dependants list. | Each dependant’s owner has heard about the link, and the list shows when. |
Check 3 scores only that a choice exists in writing, and it does not judge the choice. Check 4 matters because one change to a shared record can reach several flows.
Access and Incoming Records (Checks 5 to 8)
These four checks show who the link acts as and how it treats what arrives. They also decide how much damage a leaked credential or a bad record can do. A system integration checklist that skips them leaves those two risks unchecked.
| Check | Record to open | Ready when |
|---|---|---|
| 5. The link signs in as itself. | The account list entry for the link. | No person’s login runs the link, and the last sign-in came from the link. |
| 6. Permissions are trimmed to the job. | The permission list from each application. | The link reads only where reading is enough, holds no admin rights, while each permission has a reason beside it. |
| 7. A named person holds the credentials. | A note with the storage place, the holder, the last change and the expiry date. | No copy sits in code, shared documents or chat, and someone has run the leaver route once. |
| 8. The link tests each record when it arrives. | The rules for type, range and required fields. | When a bad record was sent in test, the link refused it and set it aside. |
Check 8 treats the other application as an outsider. An open security-community list (2023 edition) notes that developers tend to trust data from third-party interfaces more than input typed by users, which is the habit this check tests.
Application Integration Checklist: Failure and Proof (Checks 9 to 12)
These four checks show what happens when a record goes wrong and who agreed the link works. A go-live checklist for integrations has little value without them, because a link that has not failed in test has not shown how it fails.
| Check | Record to open | Ready when |
|---|---|---|
| 9. A failed record has a route to a fix. | Written outcomes for each kind of failure: the number of attempts, the gap between them, the parking spot and the person who repairs. | One parked record went back in after a repair, and then arrived once. |
| 10. A repeat send creates no duplicate. | The same record sent twice in test. | One record arrived. Mark N/A if the link only reads. |
| 11. Tests cover the awkward cases. | Results for a batch the size of the busiest day, a missing required field, a wrong type, an account with too little permission and a cancelled record. | Each case has a written result, record counts agree on both sides, and the acceptance shows which business user signed, and when. |
| 12. The go-live decision has a way back. | A dated approval with the approver’s name and the steps to undo the link. | Someone other than the builder ran the undo steps in test before go-live. |
Check 9 wants one parked record repaired and sent in again, which is a worked repair that you can show.
Watching, Changing and Leaving (Checks 13 to 16)
These four checks show whether the link stays under control when it is live. The group reads as a short system integration checklist for the months after go-live.
| Check | Record to open | Ready when |
|---|---|---|
| 13. A silent stop reaches a person. | The alert rule, plus a test alert and the reply it drew. | A deliberate stop in test alerted the person on duty and a deputy, and a day with zero records also raised an alert. |
| 14. Logs show what moved and hold no secrets. | Three log entries. | Each entry has a time, a record reference and a result, and none holds a password, a token or personal data the log does not need. |
| 15. A change to either application reaches the link’s owner first. | The last change with its review note, and the route for supplier notices. | The review happened before the change reached the live link, and the notice route names a person. |
| 16. An exit route exists. | Steps to switch the link off, who hears about it, what happens to held records and how credentials come out. | The steps run in order, each has an owner, and a review date sits on the page. |
Check 14 also has a clear outside reference. Community guidance (the page shows no date) on what a log should leave out lists passwords, access tokens and keys among the items to remove, mask or protect.
From Marks to a Go-Live Decision
Count the Not ready marks in each group first, then add the total. Signisys suggests one go-live line: no 0 on checks 5 to 12, and every 1 on those checks has an owner and a date. Checks 13 to 16, in contrast, may go live with a dated fix. This is a suggestion for your own decision, not a standard, a certificate or a pass mark.
Fix gaps in this order: access, then failure and proof. In Signisys’ view, a leaked credential or a lost record does more harm than a missing alert.
Score again when either application changes, and keep each sheet with its date and sample. A second reader should mark the sheet. The builder knows what the link was meant to do and may read a record with that in mind.
Key Takeaway Fix any Not ready mark in checks 5 to 12 before go-live; a Partly ready mark can wait if it has an owner and a date.
What This Application Integration Checklist Leaves Out
This list scores readiness for one link. It does not teach the build, so the build order for one link covers that job. It also leaves out cost, so what poor links cost a business covers that. Figures that combine data from many sources have their own list of scored checks for moving and combining data.
It does not compare ways to build a link, and it gives no legal advice. To weigh up ways to build a link, read a trial of two options on one real link, with questions to ask first. No India or GCC rule is claimed here, so check your sector’s rules with the person who owns them.
A full score proves nothing about security. Get a specialist test for a link that carries sensitive records.
Signisys provides application integration work, but you can score a link without us. Read this as a provider’s view. Our data and business intelligence integration solution page and the data, analytics and AI services page cover the work beyond this list.
Application Integration Checklist FAQ: Questions Answered
Can the application integration checklist be used on a link that is already live?
Why should the builder not mark their own link?
How long does a score stay valid?
Which Not ready mark should be fixed first?
Is a security test still needed after scoring?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.