Everything you need to run ITSCM testing at Swiss Life AM.
A calm, structured place to learn the role before your predecessor leaves — the concepts, the day-to-day workflow, and exactly how the tools (Jira, Xray, Confluence) fit together. Work through it in order, or jump to what you need.
Your job, in one sentence
You make sure Swiss Life AM can recover its critical IT services after a disaster — and you prove it works by testing, so the company satisfies regulators (DORA, FINMA) and avoids a multi-million recovery bill. You don't run every test yourself; you organise, prepare, and document, and you support the people who own the systems.
1. RTO = max downtime · RPO = max data loss · 2. S1 = no data loss · S2 = data loss · S3 = ransomware · 3. O1 fixes S1 · O2 fixes S2 · O3 fixes S3 · 4. IRRP = recover one system · FRCP = recover everything, in order · 5. BCM is the boss; ITSCM is its IT arm · 6. DORA + FINMA require you to test recovery and prove it.
How to use this hub
- Read sections 00–03 first for the big picture, then 04–06 for the tools and the plan you'll live in daily.
- Tick off the checklists as you go — progress saves in your browser and shows in the sidebar.
- Preparing before you start? Go to the 40-day study plan — one 30-minute session a day, with a calendar file for daily reminders.
- Anything marked confirm is my best reading of a noisy recording — verify it with your colleague before relying on it.
The Test Manager as an enabler
This was the core message of the handover: you are not expected to personally execute every test. You coordinate, prepare, simplify, and follow up so the application owners (the specialists) can get their systems tested without drowning in work.
"Don't give them a fish — show them how to fish." You give owners a repeatable structure and a nudge, not a finished test. Most people thank you for the support; a few need patience. Persistence wins: steter Tropfen höhlt den Stein.
RTO, RPO, scenarios & solutions
Two numbers and four scenarios sit under everything. Master these and the documents read themselves.
Geo-redundant sync
Two data centres, data synced. If one dies, fail over — no data loss.
Geo-redundant backup
Backups at both sites. Restore after data loss. Mandatory for every productive app.
Immutable backup
WORM storage attackers can't change or delete. The ransomware insurance.
From "we should test this" to a green tick
The practical workflow she walked through on screen. The golden rule: get as close as possible to a real disaster scenario without touching production — you almost always build and run in a UAT / test environment.
Two worked examples she showed
Connection test in UAT
Precondition: network & security up. After the tunnel is back, the connection re-establishes. Test cases were written as steps 1-2-3-4; production was never touched. Result: successful, with one config gap logged as a defect.
Start vs. Recover
Two data centres — St. Gallen (primary) and Chur. A Start just brings systems back up (S1); a Recover restores the whole environment from backup (S2). Run yearly with the provider (Inventx).
Keep your ears open. When a real restore or data-centre switch happens (often over a weekend after dev work), you can document it retroactively as an ITSCM test — it saves building one from scratch. Ask teams to tell you when they happen.
The tool logic: how a test is structured
Every test lives as a small tree of linked Jira items. Learn this hierarchy and you can read, build, or pick up any test. These are the five building blocks she called the heart of the job.
The test initiative — one app (or interface), one cycle
The container for everything about testing an application in a given year. Luxembourg and others click into the Epic to see how a test ran. If a related app shares an interface (e.g. Maxis + Salesforce), they can share one Epic.
What is being validated
Describes the scenario in business terms — including which of S1 / S2 / S3 applies. Reusable next cycle; you don't reinvent it each year.
The container for the test cases
Groups the test cases for this initiative and tracks their execution.
The actual steps
Step 1-2-3-4… with preconditions and expected results. This is the part she said could be auto-generated into the Word report later.
Your own to-dos
e.g. "prepare the report," "chase the owner." How you track the coordination work that's yours, not the specialist's.
What failed, and the fix
Copied straight out of the failing test case (all the info comes with it). You assign it and set criticality (critical / medium). A test with an open defect is a failed test until it's fixed and re-run.
A test moves through a small set of statuses. The dashboard groups everything by these so you always know what needs your attention.
| Status | Meaning | Your action |
|---|---|---|
| To Do | Planned, not started. | Plan it, agree a date with the owner/provider. |
| In Progress | The test is running. | Support, follow up, watch for defects. |
| Reporting | Test done, waiting on the report. | Chase the owner to fill & sign the report. |
| Done | Complete and closed. | Mark green in the plan; inform the relevant countries. |
confirm In the Excel plan, colours also flag test outcome: black = planned · red = failed (needs rework) · green = done. (Application-category colours are covered in section 06.)
- Talk to the app owner / provider and agree what and when (e.g. "we'll test in Q3").
- Create the Epic, then the User Story, the Test Plan and its Test Cases.
- Add a Task for yourself (usually: prepare the report).
- Copy the report template (based on the Swiss Life AG one, adapted to your environment).
- Build the environment in UAT, run the test, capture timing vs. the RTO.
Plan Q1 in Nov/Dec. September is quiet. Q1 is mostly re-tests (things that failed and need rework) plus small clarifications. Contact everyone from mid-January to mid-February to lock the year.
Defects are normal — early on a batch of tests can throw 15–20+. Each is copied from the failing test case, assigned, and given a criticality. You stay on them until fixed.
- Many defects are script-related: the recovery script didn't run cleanly. The person who owns the script finds the root cause, adapts it (often alongside a new version), and you re-run and re-document the test until it goes green.
- You can automate the nudge — log a work item; if nothing happens, send a mail.
- A recovery-plan gap found in discussion with technicians (e.g. "responsibility for Bloomberg Terminal connections isn't mapped") also becomes a defect.
When the test is done, the report is filled by the person who knows the product (there's no lock on a shared Word file, so the owner — not you — edits it) and each participant adds a dated comment in the report's chapter 5.
Reto reviews, then it goes to the business manager. The report is signed off by the Application Manager, ITSCM Manager, Reto, and Business Manager.
The Dashboard in Jira rolls everything up by status (To Do / In Progress / Reporting / Done). Note: closed items get archived each year — archived Epics won't show in a normal search, so keep the master list of Epic links.
The map: where to find what
Almost everything is documented in Confluence, with links out to the plan (Excel), the process models (ADONIS), and templates (SharePoint). Here's the map she gave you.
| Where | What's there | Why you need it |
|---|---|---|
| Confluence · Operational Resilience | The summary landing page tying it all together; the Strategy PDF and the Testing Framework instructions are linked/embedded. | Your home page. confirm some content is being refreshed to current state. |
| ADONIS (Swiss Life) | The BPM process models — roles, who does what, per country, the Emergency Organisation process. | You'll need the "IT Testing" permission. Click a role to see its tasks. |
| Excel · Test Activity Plan | The master plan of all apps, tiers, countries, and scheduled tests (see section 06). | Your day-to-day planning tool. Maintained by your team; Luxembourg reads it. |
| Jira Dashboard | Live status of every test initiative, grouped by status. | Your "what needs attention today" view. |
| SharePoint · Testing | Templates (report, etc.). Some old PowerPoint/Word templates are retired — she now uses one. | Grab the current report template here. A name on a file doesn't mean that person authored it. |
| Team channel (Teams) | The working links, the document repository, and a Whiteboard with the exercise agenda & per-stage checklists. | Guests (auditors) get access here. The whiteboard shows what each stage of the process requires. |
There's a dedicated process (Reto is building it and will walk you through it). You'll be registered in the org, and there are laminated cards for it. Each stage has a checklist and questions to prepare (e.g. for management support).
The Excel master plan
One spreadsheet drives your year: every in-scope application, its tier, which countries use it, the infrastructure it runs on, and when it's tested. The goal is to consolidate all test plans into this one master over time.
Tiers & cadence
| Tier | Meaning | Cadence |
|---|---|---|
| Tier 1 | Most critical apps. | Tested most often (e.g. 2025, then every 3 years → 2028). |
| Tier 2 | Important. | On the 3-year rhythm; sometimes pulled forward. |
| Tier 3 | Lower criticality. | Around 2027 in the current cycle. confirm |
| New / yearly | A category they added; plus items required yearly. | Yearly (e.g. the DC Start/Recover and the Full Recovery). confirm |
Colour legend
confirm the exact colours — this is my reading of the walkthrough; verify against the live sheet.
Who uses each app (the country columns)
Columns flag which entities use an application — Switzerland, Germany (incl. KVG, a separate German company), Luxembourg, France, Norway. When a test finishes you use these to know which countries to inform. Contacts live in the notes column (e.g. the Norway manager).
How planning actually works
- Each year's Epics are created ahead of time: she makes the next year's Epics around Dec/Jan, then contacts each owner/provider to confirm timing.
- You can't just declare "I'll test X in Q1" — you agree a slot with each owner ("no time in Q1, but Q4 2027 works").
- Future years hold placeholders (e.g. 2027, 2028) with a short comment on how the plan was derived — the workload looks like a "bathtub": heavy, then lighter, then heavy again.
The Excel is static — after you change anything in Jira, tidy the Excel by hand so they stay in sync. A big future project (SimCorp Dimension / "SCD" as a SaaS service, release ~April) will reshape testing; Roland leads test management there. Expect the framework to slim down.
The November–December cycle — your hardest deadline
This is the most time-critical thing Prisca handed over. You arrive in September; the year’s biggest deadline-driven cycle begins six weeks later and runs on fixed dates.
If you start in September, get into this by early October at the latest — better earlier. Scoping, verifying the Control Procedures and booking the walkthrough dates all have to happen before 1 November.
The risk if you don’t: on 1 November a whole battery of Control Procedures fires automatically at ~30 Application Owners who, in her words, “definitely won’t know what it’s about any more.”
| When | What happens | Your part |
|---|---|---|
| Early Oct | Preparation window. | Scope the CIF list, verify every Control Procedure, book the walkthrough dates, warn the owners. |
| 1 Nov | Control Procedures fire automatically to ~30 owners (+ deputies). | Confirm they actually went out; send a short explanatory note. |
| 1–30 Nov | Owners review their IRRP. They have 4 weeks. | Cross-check each one, get Reto’s approval, upload the PDF to Fact24, chase stragglers. |
| Week 1 Dec | The Full Recovery Plan walkthrough. | Run it — in four groups of ~1.5h, not two of 3h. |
Last year most Control Procedures went out on 4 Nov; this year it will be 1 Nov. Two were piloted first.
Never let new work land in November. November is only for checking what already exists — did links, people or support contacts change? Anything genuinely new must be built during the year: Bloomberg had to be split into Terminal + FIX Connections, and Axioma became a new CIF with no IRRP at all. Both were handled early, so November was just a glance.
How the review actually flows
Every CIF (Critical Important Function) — about 30 applications, all listed in the Excel plan — has its IRRP reviewed once a year. The mechanism that drives it is a Control Procedure in Jira.
A Jira mechanism built by Romano (Atlassian team) — not just for ITSCM. Many people use it for recurring obligations: it reminds them, they complete it, and it becomes audit evidence.
- Starts 1 November, deadline 30 November — four weeks.
- Contains a generic link to the IRRP folder (generic so each procedure doesn’t need editing).
- Every Control Procedure needs two named people — a Control Performer and a deputy — so it survives someone leaving.
- A new CIF app means a new Control Procedure. Ask Romano — he built it, he’s proud of it, and you get full support.
- They all hang off one internal control (ICS): IT Restart and Recovery Plan and Full Recovery Plan.
Prisca was refreshingly blunt about the limits of your role.
Read diagonally
What changed? Does it exist? Is it plausible? Does it match the BIA / RTO / RPO? Do the links still work? Track-changes shows you the diff against last year.
Technical depth
Server names and configuration detail are the owner’s responsibility. In her words: “whether the server is called that — I don’t care. That’s not my responsibility.”
The IRRP belongs to the Application Owner. You manage that it gets reviewed, questioned, approved and stored. Reto, as ITSCM Manager, digs much deeper than you will.
What the owner must check: IT service information and contacts, responsibilities, the Restart Schedule, the Recovery Schedule (3.2), that links work, and the return-to-normal-operations steps.
| Version | Meaning |
|---|---|
| x.9 | The owner has reviewed it. Status Reviewed/Changed, with their comment and name on page two. Awaiting approval. |
| x.0 | Approved by Reto (four-eyes principle). Final. e.g. 1.9 → reviewed → approved → 2.0. |
SharePoint versioning is deliberately switched off — they consciously moved away from keeping versions. You see what changed through track-changes instead.
Every approved PDF must be uploaded to Fact24 manually. Nothing synchronises. If it changed, re-upload it.
The Full Recovery Plan is at v2.0, produced from last December’s walkthrough. Red entries are open items for the next one — there are always some. Next time: copy it to v3.0 to keep the history.
- Group 1 — all of Shared IT together, from the IT basis infrastructure (Recovery Class 10) upward. Keep them in one room: their cross-talk is where the value is (“no, if you have that, you also need this”).
- Groups 2–4 — business applications. Only apps with CIF = Yes are reviewed; “No” apps like DocuSign stay in the plan but are skipped.
- The sequence starts with Full Responsibility of Providers (an assumption, no IRRP), then Break Glass (Azure, Zscaler), then Network — Break Glass must finish before Azure Network Cluster starts.
Two groups was a mistake: too big, and the people at the end just waited. Feedback was that it was boring and people disengaged. The fix: four groups of 1.5 hours instead of two of three hours. Prisca had no recipe yet — she said explicitly to work the grouping out with Reto.
You must explain Blocking / Semi-Blocking / Non-Blocking at the start so everyone understands the sequencing. The definitions sit in a collapsible section at the top of the FRCP sheet. Prisca still didn’t find them great — clarify anything unclear with Reto, and reuse her slides.
The lifeboat
Fact24 is what you use when you have nothing — no Confluence, no Jira, no SharePoint. It’s hosted externally on AWS, completely separate from Swiss Life systems, bought by the Holding group for crisis management. Login is single sign-on.
Everything in Fact24 is uploaded manually. There is no synchronisation with Confluence or SharePoint. Every time an IRRP or the FRCP changes, the PDF has to be re-uploaded.
Your place in it
You are Management Support, alongside Reto, Roland and Mark — you manage the process, not the technical fix. The ICT EO Head (Head of Shared IT + Head of Security IT) owns the problem-solving and decides who is needed.
- Everyone joins the first call — that’s the deliberate strategy. Then people drop out if they’re not needed, and can be pulled back in.
- The Head works from a checklist — Prisca called it “extended memory” — so no point is forgotten.
- Scope is IT situations only. Building evacuation and the general crisis staff are a different department entirely.
- Alarms fire on three channels in parallel: SMS, email and phone call.
- Everyone with a role has triggered a test alarm at least once, so it never depends on one person. They rotate.
- Q3 exercise: Reto leads and is the Master. You’re Management Support with him and Roland.
Prisca documented the entire Fact24 setup on a Confluence page — how she configured persons, groups, qualifications, alarms and templates, and how to trigger an exercise alarm. She noted she was “pretty much the only one who worked into this,” so locate that page in your first weeks.
What to do, week by week
Everything below works backwards from 1 November. The full version lives in 06_My_Notes/First_90_Days_Playbook.md; the checklists in section 14 track it.
Get switched on
Chase access (Jira/Xray, Confluence, SharePoint, the private EO channel, Fact24, ADONIS). Get swapped in for Prisca on the Two-Pager and on every Control Procedure. Meet Reto, Roland, Romano and Mark.
Learn the live picture
Read the Epics Prisca annotated with status before leaving — that’s her written handover. Open the finished eFront report as your model. List the ~30 CIFs with owners and tiers. Read 3–4 IRRPs and the FRCP.
Prepare the cycle ⚠
Confirm the CIF list, create any missing IRRP, verify every Control Procedure points at the right two people, and book the December walkthrough dates now — people are booked out early.
Run it
Cross-check ~30 reviews, get approvals, upload each PDF to Fact24, then deliver the walkthrough in four groups and produce FRCP v3.0.
Ten things she’d tell you on day one
| # | Advice |
|---|---|
| 1 | Get into the November cycle by early October. Everything else can wait; this can’t. |
| 2 | You’re not the technical expert — and you’re not supposed to be. |
| 3 | Never let new work land in November. November is for checking what exists. |
| 4 | Persistence is the actual skill. Keep coming back; keep offering to take work off people. |
| 5 | Write it down. Anything told to you verbally “floats somewhere in the air” — put it in the Epic. |
| 6 | Use DORA as the lever. “We must, by law” unlocks time, money and cooperation. |
| 7 | English by default. With English you’re always fine; with German you can lose someone. |
| 8 | Everything in Fact24 is manual. Nothing syncs. |
| 9 | Ask Romano for anything Jira or Control-Procedure related. |
| 10 | Four small groups, not two big ones. People switch off in a three-hour walkthrough. |
Who's reachable, and who gets called
Why "Best Effort" outside business hours is a deliberate, cost-based choice — and how you interface to the Emergency Organisation.
Types → Methods → Modules → Packages
The formal structure from the AM 12.1.1 framework. You'll mostly work in theoretical (reviews / walkthroughs / questionnaires) and practical (single & multi tests) modes, with the big overall exercises once a year.
For DORA, a set of ~25 services got a theoretical interview questionnaire that owners answered; responses were checked and completed by the 10 Jan 2025 deadline. It's all captured under one Epic — a good template for the theoretical type.
What each handover covered
Reconstructed from the recordings (rough Swiss-German transcription — treat confirm items as to-verify). Expand each.
- Your role is an enabler, not a doer — six working principles (see section 01).
- How a real test gets built, and the shortcut of documenting real events as tests (section 03).
- The on-call reality: no paid 24/7 standby; "Best Effort" outside hours; follow-the-sun (section 07).
- Tooling is Jira/Xray + Word reports; audits (DORA) need a complete, gap-free overview.
- Logistics: Wednesday is the on-site day; Reto will introduce you.
- She spoke High German so you could focus on the substance, not the dialect.
- Toured Confluence (Operational Resilience page, Strategy PDF, framework, ADONIS processes, Emergency Org) — section 05.
- Toured the Test Activity Plan (tiers, colours, countries, cadence, placeholders) — section 06.
- Drilled into a live Epic → Story → Test Plan → Test Cases → Report, with the Bloomberg and data-centre examples — section 04.
- Explained defects, sign-off, the dashboard, and yearly archiving in Jira.
- Your scope is 50% ITSCM testing + 50% supporting Roland; the future SimCorp Dimension (SCD) SaaS project will reshape things.
- Key dates: an event on 8 Aug; SCD release ~April; next session on the 22nd.
- Toured the ITSCM Teams channel — mainly a filing place, plus a private EO channel only EO members can see. The Two-Pager is now verified and laminated copies go out physically.
- Walked the Recovery Documentation: the IRRPs and the Full Recovery Plan, plus archive folders for decommissioned and no-longer-CIF apps.
- Explained the annual IRRP review driven by Control Procedures in Jira — 1 Nov to 30 Nov, then the walkthrough in week 1 of December (sections 07–08).
- Showed Fact24: the SIM document store and the ENS+ alerting world, and the whole ICT Emergency Organisation structure (section 09).
- Confirmed all EO communication is in English; the company language is English.
- Background: the SimCorp release is running suboptimally (first time on the newest release, needed for the on-prem → SaaS move), targeting 8 August go-live. Roland finishes it after she leaves; next release maybe May/June 2027.
- She is documenting the status of every running test inside the Epics before she goes, so it’s accessible to Reto too. The eFront test and report are complete.
- She’ll ask Reto whether Mark Zwigart (In and Out), the external who ran this before her, can support your first cycle.
Got the next recording? Add it here — send it over and this section (and the checklists) will be extended.
Track your readiness
Tick items off as you complete them — progress saves in this browser and feeds the sidebar meter. HOT marks the highest-priority items.
First weeks — access & setup
Create one test, end-to-end
The Nov–Dec cycle (your biggest deadline)
Ask in session 3 (the 22nd)
30-day readiness (after she leaves)
Quick reference
Terms you'll hear daily
| Term | Meaning |
|---|---|
| Epic / Story / Test Plan / Test Case / Report | The five building blocks of every test in Jira/Xray (section 04). |
| Xray | The Jira plug-in for test management (Test Plans, Test Cases, Execute). |
| Defect / Bug | A logged failure, copied from a test case, with a criticality. |
| Start vs. Recover | Start = bring a healthy system back (S1). Recover = restore from backup (S2/S3). |
| Full Recovery (FRCP) | The yearly rebuild-everything-in-order exercise. |
| UAT | Test/acceptance environment — where you run tests without touching production. |
| ADONIS | Swiss Life's process-modelling tool (roles, responsibilities, the Emergency Org process). |
| Tier 1 / 2 / 3 | Application criticality bands that drive test frequency. |
| KVG | A separate German Swiss Life company (a country/entity column in the plan). |
| MoD | Manager on Duty — ~4 people you contact for out-of-hours issues. |
| RTO / RPO | Max downtime / max data loss (section 02). |
| S1 / S2 / S3 | No data loss / data loss / ransomware. |
| O1 / O2 / O3 | Geo-redundant sync / geo-redundant backup / immutable backup. |
| DORA / FINMA | EU regulation / Swiss regulator — both require tested, provable recovery. |
| CIF | Critical Important Function — an app critical enough to need an IRRP and an annual review (~30 of them). |
| Control Procedure | The Jira mechanism that fires the annual IRRP review on 1 November and records it as audit evidence. |
| ICS | The internal control framework. One ICS control covers the IRP + FRCP; all Control Procedures hang off it. |
| Fact24 | External AWS-hosted platform: document store (SIM) + alerting (ENS+) for when everything else is down. |
| Two-Pager | The laminated contact/role card for the ICT Emergency Organisation. You’re on it as Management Support. |
| Break Glass | Emergency-access accounts (Azure, Zscaler) — the true first step of the Full Recovery sequence. |
| Blocking / Semi- / Non-Blocking | Whether a recovery step must finish before the next can start. You must be able to explain these. |
| Recovery Class | The ordering bands in the FRCP, starting at Class 10 (IT basis infrastructure). |
| x.9 / x.0 | IRRP versions: x.9 = reviewed by the owner, awaiting approval; x.0 = approved and final. |
| Inventx | The provider for the St. Gallen / Chur data-centre tests. |
| SimCorp Dimension (SCD) | Major SaaS project reshaping future testing; Roland leads its test management. |
People & culture
Your circle
Prisca — your predecessor. Reto — ITSCM Manager: approves IRRPs, owns strategy, leads the Q3 exercise. Romano (Atlassian team) — built the Control Procedures; ask him for anything Jira. Mark Zwigart (In and Out) — the external who may support your first cycle. Reto — your predecessor. Reto — ITSCM Manager: approves IRRPs, owns strategy, leads the Q3 exercise. Roland — you support his role 50%; he finishes the SimCorp release. Romano (Atlassian team) — built the Control Procedures; ask him for anything Jira. Mark — fellow Management Support in the EO. Mark Zwigart (In and Out) — the external who ran this before Prisca; may support your first cycle.
Roland — you support his role 50%; he keeps the journal in exercises, knows the process. App owners / technical contacts — the specialists you enable.Mostly remote
Wednesday is the on-site day (Reto & Roland usually in). ~95% of meetings are Teams chat/calls; even a Security CAB you might lead is remote. Go say hi in person when you can — relationships build over time (and coffee).
Dates to hold
| When | What |
|---|---|
| 1 Sep | Official handover info starts arriving on your Swiss Life email. |
| The 22nd | Next handover session (the "Full" walkthrough + Emergency Org with Reto). confirm |
| 8 Aug | An event she mentioned; after it, fewer sessions this year. confirm |
| Q3 | First exercise you'll take part in. |
| Early Oct | Prepare the annual cycle — scoping, Control Procedures, book walkthrough dates. Non-negotiable. |
| 1–30 Nov | IRRP review window — ~30 Control Procedures, four weeks. |
| Week 1 Dec | Full Recovery Plan walkthrough — four groups of ~1.5h. |
| Mid-Jan – mid-Feb | Contact all owners to lock the next year’s test plan. |
| ~April | SimCorp Dimension (SCD) SaaS release. confirm |
40 days to get ready
One focused session a day, about 30 minutes, from 23 July to 31 August. Import the calendar file for a daily reminder at 19:00, and tick each day off here as you go.
Every session has one goal, and the goal is always “be able to explain this without looking” — not “have read it”. Reading feels productive; explaining is what sticks. If you can’t say it out loud at the end of a session, repeat that session rather than moving on.
Sundays are deliberately lighter — review and consolidation, no new material.
Mac
Double-click ITSCM_Study_Plan.ics. Add it to a new calendar called ITSCM so you can hide or delete the whole thing later in one go.
iPhone / Google
iPhone: email the file to yourself and tap it. Google Calendar: Settings → Import & export → Import.
Different time?
Events are set to 19:00 with a 10-minute heads-up. Select them all in your calendar and drag, or ask for a regenerated file at another hour.
Don’t binge to catch up. Continue from where you are — week 6 is consolidation and can be shortened without losing anything important.