Purpose and outcome
Connecting business applications often grants one service the ability to read or change information in another. A booking tool may read customer records, a reporting dashboard may collect sales data, and a messaging service may send reminders. These arrangements can be useful, but they also create permissions, dependencies and obligations that are easy to forget after setup.
An integration access register gives a small team one reliable place to answer practical questions: Which systems are connected? Who owns each connection? What data moves? What access does the integration have? How would we disable it safely? The register is not a replacement for an application inventory, risk assessment or contract review. It is a compact operational record that connects those activities.
This guide sets out a repeatable method for creating a register, verifying the permissions actually granted and reviewing whether the integration is still needed. It is designed for organisations with limited IT resources and multiple cloud applications. Start with the applications that handle critical operations or customer information rather than trying to document every low-risk connector in one afternoon.
1. Identify the systems and the business reason
List the applications involved in an integration, including their vendor names, environment, responsible business process and primary owner. Use the product name users recognise, then add a technical identifier or tenant name if needed. Avoid storing passwords, API secrets or recovery codes in the register.
Describe the business purpose in one sentence. “Moves confirmed bookings into the team schedule” is more useful than “Calendar sync”. A purpose statement allows a reviewer to decide whether the connection remains necessary after a process changes.
Record the source and destination. Some applications exchange data in both directions; note both paths rather than assuming a one-way transfer. If a third-party automation service sits between two systems, include it. An owner may think two products communicate directly when information is actually processed and stored by another supplier.
Where integrations support finance, healthcare, legal matters, education or another regulated context, record the accountable professional or business owner and seek the appropriate sector-specific review.
2. Inventory the permissions actually granted
A vendor’s advertised capability does not tell you the rights granted to the current connection. Review the application’s administration or consent screen and record the effective scopes and roles. Distinguish read access, write access, user administration, exports, deletion, payment actions and permissions to connect further services.
Apply least privilege. A reporting job that reads aggregated appointment totals should not automatically gain authority to modify customer records. A reminder service may need contact details and appointment status, but not unrelated employee or payment information. When a platform bundles permissions too broadly, document the excess and either choose an alternative, add compensating controls or escalate the residual risk.
Also record who authorised the connection and when. For organisation-wide integrations, use a managed service identity or supported application authorisation pattern instead of tying essential work to an individual employee’s personal account. Check whether the connection continues operating after its original creator leaves. This is a continuity issue as well as an access-control issue.
3. Describe the information flow
List the categories of information exchanged. For a salon booking workflow these might be booking reference, selected service, staff member, time, customer contact information and payment state. Identify which application is authoritative for each field. This prevents the register becoming a disconnected list of applications that cannot explain how an error should be fixed.
Record the trigger: a new booking, a status change, a scheduled sync or a manual export. Note whether the transfer occurs immediately or in batches. Include important transformations, such as date formats, currency handling, time zones and customer identifiers.
For personal information, identify why each category is needed and whether retention is proportionate. The UK Information Commissioner’s Office explains the principles of data minimisation, accuracy, purpose limitation and accountability. The organisation’s actual legal duties depend on the jurisdiction and purpose of processing; the register helps surface questions for qualified review without claiming to answer them.
Do not copy live customer records into the register. Field categories and example test records are usually sufficient.
4. Capture credentials without exposing credentials
Record the authentication method and where the credential or authorisation is managed, not the credential itself. A register might state “OAuth connection administered in the vendor console by the Operations application owner” or “Service token held in approved secrets storage”. It should never include token values, private keys, passwords or recovery codes.
Include credential expiry or review dates when known. Document the revocation procedure and identify the person who can perform it. For a connection with payment or privileged access, make sure at least one authorised backup administrator can respond to an urgent incident.
Understand the difference between rotating a token and safely disabling an integration. A token replacement may preserve workflow continuity; full revocation may halt reminders, exports or customer-facing services. Both actions need an operational plan.
Where possible, restrict integration access to specified resources rather than entire accounts. Review the supplier’s security logs or connection history after material permission changes.
5. Define failure modes, monitoring and ownership
Record the states that matter to the business. A synchronisation might complete, fail, remain pending or report success while the receiving application rejects a record later. The owner needs a way to distinguish those outcomes.
Specify the expected frequency of data movement and how failure is detected. “Daily review of unprocessed records” can be a suitable control for a low-volume process. A high-volume or business-critical connection may need automated alerting on repeated errors, unusual changes and missing expected activity.
Identify the first responder and the business owner who can decide whether to pause the connection. Include the safe manual fallback, if one exists. If a booking update fails, which calendar should staff trust, and how should corrections be reconciled after recovery?
Monitor access changes as well as transfer failures. If a connector suddenly asks for additional permissions, the change should trigger review rather than automatic consent. Application upgrades and vendor product changes may alter what a connection is allowed to do.
6. Test the access boundary
A register should reflect reality. With proper approval and a non-production or safely controlled environment, verify that the integration can complete its intended task and cannot perform unrelated actions. Test an authorised record and a record outside the intended scope when the platform supports such testing.
OWASP’s API Security Top 10 highlights broken object-level authorisation and broken authentication. In a multi-customer application, knowing a record identifier must not be enough to access or change that record. A credible review therefore considers both the role granted to an integration and how the application enforces the right to access individual records.
Use benign test data, record expected and actual outcomes, and avoid broad vulnerability scanning against third-party services without authorisation. If the vendor does not offer a practical way to test a permission boundary, document that limitation rather than marking the control as verified.
7. Prepare for changes and vendor departure
Record an exit action before the connection becomes business critical. How is data exported? Which records would be left behind? What customer communications would stop? Can the system return to a manual process without duplicate bookings or charges?
Retiring an integration is not simply deleting a token. The team may need to preserve records for a legitimate business or regulatory purpose, confirm transfers have stopped, remove the supplier’s access, reconcile the last processed events and inform staff of the new operating procedure.
A change to scope, vendor, data categories, payment capability or responsible owner should trigger a new review. Treat newly granted authority as a meaningful change, even if the product interface still looks the same.
8. Apply a practical review cycle
Review high-impact integrations when a material event occurs and at a periodic interval appropriate to risk. A six-month review is a reasonable proposed starting point for a changing small-business SaaS environment, but it is not a universal standard or legal requirement. Lower-impact connections can be reviewed less frequently if justified.
An effective review asks whether the business purpose still exists, whether the owner is still accountable, whether permissions remain necessary, whether logs and failure alerts are working and whether there have been material vendor or contract changes. It also checks whether previously recorded exceptions have been resolved.
Record the review date, reviewer, evidence, decisions, outstanding actions and next review. Do not represent an unchecked permission as verified. If information is unavailable, mark it as unverified with a named action and due date. Honest uncertainty is better than a green status invented to complete a table.
Register template
Create one row per integration and include the following fields:
- Integration ID and descriptive name
- Source and destination applications, including intermediary platforms
- Business purpose and accountable owner
- Technical administrator and approved authorising role
- Data categories and system-of-record decisions
- Trigger and expected transfer frequency
- Effective access scopes and any excessive permissions
- Authentication method and secure credential-storage reference
- Supplier, processing location and relevant contractual review reference
- Last successful test and latest security review date
- Monitoring or log source and escalation contact
- Safe pause/revoke method, fallback and exit procedure
- Risk rating, exceptions, next review date and evidence links
Use links to controlled internal records rather than embedding customer information or security secrets. Limit access to the register itself because it describes sensitive relationships between systems. Keep a change history so reviewers can understand when permissions or owners changed.
A short example
Example only, not a Tavryqen customer or deployed integration:
Integration ID: INT-004. Booking Platform → Customer Reminder Service. Purpose: send appointment confirmations after a booking reaches the confirmed state. Owner: Business Operations. Trigger: booking status change. Data: booking reference, appointment time, customer contact route, communication preference. Expected outcome: one correct confirmation for each eligible change.
Permissions to verify: read confirmed bookings and approved contact fields; no payment modification or user administration. Authentication: managed application authorisation, recorded without secrets. Monitoring: daily failures summary, missing-confirmation exception list. Fallback: authorised staff issue confirmations from the booking system using a documented manual method. Revocation: disconnect the reminder service, reconcile pending messages and confirm no later messages are sent. Status: NOT YET VERIFIED.
This example demonstrates the level of detail that makes a register useful. Do not copy its access assumptions into a production system. Validate actual supplier behaviour and permissions.
Implementation checklist and review evidence
Before approving a connection, confirm that a business owner is named, the intended outcome is defined, the minimum data is specified, effective permissions are documented, credentials are protected, failure states are understood, a safe revocation procedure exists and the integration’s review date is recorded.
For an existing connection, compare the record against the current administration console. Record screenshots or exported configuration evidence only when permitted, store them in a controlled location and avoid including secrets. Confirm at least one expected event and one controlled failure path. Escalate unexpected rights or unexplained data movement for investigation.
For the programme as a whole, measure how many critical integrations have a named owner, reviewed permissions, current test evidence and an agreed fallback. A count of registered connections alone is not evidence that the environment is governed.
For security governance, NIST CSF 2.0 offers a framework for managing risk proportionately. The purpose of this register is to make such responsibilities concrete enough for people to act on them.
Scope and limitations
This guide does not guarantee security, compliance or uninterrupted service. An integration register is one piece of a wider inventory, access-control, supplier-risk and incident-response practice. Regulatory obligations vary, and payment, clinical, legal, employment and safety-critical activities may require additional controls and qualified review.
An accurate register should be used in change reviews and operational incident response, not filed away after a one-time project. Keep it practical, assign responsibility and update it when the connected environment changes.