Write responsibilities as actions
“The provider handles security” is too broad to use during an incident or a purchasing decision. “The provider patches the database service, and our team controls the website deployment account” describes work that can be assigned and checked.
Responsibilities change with the service model. A virtual server, a managed database and a finished software application hand over different amounts of operational work. Microsoft’s cloud responsibility guidance illustrates this principle. It does not define the contract for another provider. For your own system, identify who configures, operates, reviews and responds for each important component.
Map the handoffs in one customer journey
Follow a customer from your homepage through login to a saved record. List the website, the authentication service, the application data service and any analytics or support tools receiving information. Add the accounts that can change each component. This reveals control points that a simple list of hosting suppliers can miss.
| Control point | Question to resolve | Evidence to keep |
|---|---|---|
| Website deployment | Who can change the code customers receive? | Account owner and access review |
| Hosted application service | Which operational tasks does the provider perform? | Documented scope and contract |
| Customer access | Who defines and checks permitted actions? | Permission rules and test results |
| Service interruption | Who communicates, investigates and restores work? | Named contacts and recovery procedure |
Understand a failure that crosses the boundary
Consider an illustrative booking website that loads a marketing script. Its customer records are hosted elsewhere. If the script becomes malicious, it could copy information displayed on the booking page or alter what the visitor submits. The hosted database need not be compromised for that customer to be affected.
OWASP’s third-party JavaScript guidance explains the risk of giving outside scripts access to page data. The operational lesson is to identify which team approves scripts and which pages should load them. A public homepage and a signed-in customer page do not necessarily need the same integrations.
In this example, the provider investigates its service while the website owner removes the unsafe integration and checks affected sessions and workflows. Both sides need a contact path.
Apply the worksheet to Gammal Tech
Gammal Tech provides hosted login and per-user application storage. An application can use these services without operating those backend functions on its own web server.
Your team still controls the website code, domain, hosting administration and integrations it introduces. Give someone responsibility for protecting data returned to the browser and for deciding which business actions a customer may perform. A registered domain does not establish that every script delivered from that domain is safe.
For matters not explained by public documentation, ask specific supplier questions. Which records are recoverable, through what process, and who contacts whom during an incident? Capture the answers before your workflow depends on them.
Test the handoff before launch
Run a short tabletop exercise with a business owner and the person maintaining the website. First, suppose a former agency employee still has deployment access. Identify who can remove it, which account must be reviewed and how the change is confirmed. This tests your administrative boundary.
Second, suppose a customer cannot retrieve a saved record. Decide how support establishes the affected project and time without asking the customer to send sensitive session credentials. Determine which observations belong in a supplier report and who keeps the customer informed.
Any answer that ends with “someone at the other company probably does that” identifies a missing handoff. Resolve it with an owner and a documented procedure.
Review the map when the application changes
Adding an export button, a support integration or an administrator screen can change the responsibility map. An export creates a new place to protect data. A support integration introduces another recipient. An administrator screen introduces decisions about elevated access.
Ask the same three questions during each change: what new information moves, who can control it and what happens if that component fails? Review the map after supplier changes and incidents as well. This keeps the benefit of managed infrastructure connected to the actual system your customers use.
Common questions
Is shared responsibility a 50/50 split?
No. The division depends on the service, configuration and agreement. Describe actual tasks and owners rather than assigning a percentage.
Does a provider’s security documentation prove my website is secure?
It helps assess the provider’s service. Your website code, accounts, integrations and business permissions also need evaluation because they form part of the customer journey.