We review before we commit. We document before we take over. And we agree on what happens with changes and incidents.
Amber = still open, Green = reviewed/organized. Coral is used only for actual incidents or risks. The exit is optional and part of being ready for handover.
What happens: You describe the application, its purpose, hosting and current concerns.
What we need: A short system description, a contact person, no credentials.
What you get: An assessment of whether RTT is a fit in principle.
Time frame: Usually a few business days until we schedule a call; no service promise.
What happens: We clarify criticality, stack, operating model and review needs.
What we need: A business and a technical contact, a rough architecture.
What you get: A proposal for the scope of the Operations Check.
Time frame: 30 minutes, free of charge.
What happens: We review the repository, infrastructure, security, backups and deployments.
What we need: A non-disclosure agreement, time-limited read access to repository and infrastructure, existing documentation.
What you get: A status report, prioritized findings and a takeover recommendation.
Time frame: Usually one to two weeks, depending on the size of the system.
What happens: We assess the risks and agree on the way forward together. A no is possible, too.
What we need: Risk sign-offs, internal responsibilities and a budget range.
What you get: A decision on measures and takeover.
Time frame: Depending on the findings: from a few days to several rounds of coordination.
What happens: We close the prioritized operational risks.
What we need: Test access, approvals, technical contacts.
What you get: Verifiable measures and the remaining risks.
Time frame: Depending on the findings: days to several weeks or longer.
What happens: We set up operating procedures, alerting, the runbook and contacts.
What we need: Binding approvals, operational data and escalation contacts.
What you get: A documented handover of operations with an agreed scope of service.
Time frame: Usually several rounds of coordination; the exact duration depends on the system.
What happens: Monitoring, maintenance, updates, incidents and reporting as agreed.
What we need: Change approvals, contacts and ongoing coordination.
What you get: A regular report and a traceable service operation.
Time frame: An ongoing service within the contractual service hours.
What happens: We organize the handover to you or to a new operator.
What we need: Recipient, access routes, handover date and data export requirements.
What you get: Code, data, infrastructure documentation, runbook and handover log.
Time frame: Depending on scope and contract: usually days to several weeks.
| Area | Client | RTT | Together |
|---|---|---|---|
| Source code & application logic | Responsible for content/rights | Review of changes relevant to operations | Document limits |
| Infrastructure | Owner / approval | Operation as per contract | Architecture and cost basis |
| Data & data protection | Controller | Technical measures within the agreed scope | DPA, deletion and export |
| Access | Naming/authorization | Technical administration as mandated | Least privilege & rotation |
| Updates | Business acceptance | Review, planning, implementation within scope | Change approval |
| Incidents | Impact/business priority | Detect and respond as per SLA | Escalation and post-incident report |
| Further development | Product ownership | Only if separately commissioned | Review and release approval |
This matrix illustrates the split. Only the service and responsibility matrix agreed per system is binding.
Detect → Classify → Respond → Fix → Post-incident report.
● GREEN / operational: Normal operation confirmed.
● AMBER / unclear: Cause or impact still unclear.
● CORAL / incident: Confirmed incident or concrete risk.
Handling follows the actual service hours and escalation rules.
Submit change → code/dependency review → tests and staging → business approval → controlled deployment → monitoring → rollback if needed.
No straight prompt-to-production run without a review and fallback path.
How we set up the test pipeline: the Automate building block →
Don't send secrets and credentials via a form or unencrypted email. Access is granted through an agreed secure channel; time-limited least-privilege accounts, separate roles and the four-eyes principle for critical actions.
Within the agreed scope, you get source code, a data export, an infrastructure description, a runbook, an access overview and a handover log. The time frame is agreed in advance based on the size of the system – no blanket guarantee of days.
Schematic samples – no real client data or real operating figures.
The bars show ranges and overlaps, not fixed commitments. An incident or missing access can change the approach.
Sample rhythm, to be agreed per system before signing the contract.
Test checks and alert routes, confirm contacts.
Verify recovery in an isolated environment and log it.
Assess updates, agree on change windows and tests.
Summarize incidents, updates, risks and next measures.
We review first, before we take on responsibility.
Request an Operations Check ↗