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.

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.

RTO, RPO, scenarios & solutions

Two numbers and four scenarios sit under everything. Master these and the documents read themselves.

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

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 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.

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

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 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.

Last year most Control Procedures went out on 4 Nov; this year it will be 1 Nov. Two were piloted first.

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.

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.

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.

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.

Ten things she’d tell you on day one

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.

What each handover covered

Reconstructed from the recordings (rough Swiss-German transcription — treat confirm items as to-verify). Expand each.

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.

Quick reference

Terms you'll hear daily

People & culture

Dates to hold

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.

The ground you’re standing on

You started on 1 September 2026 — the day Swiss Life launched Fit 28, a division-wide transformation. Here’s your team, and what Fit 28 means for you.

Your team — who to lean on

The five Fit 28 levers

Everyone will reference these. Learn them well enough to use naturally.

Day-1 actions

• Book 1h with Roland (Jira/Xray walkthrough) and a call with the Germany coworker.
• Read the onboarding portal; skim the Shared IT team overview; log your holidays in the Absences page.
• Join the Fit 28 town-hall / country-call follow-ups for your function.
• Consider the Sports Club (~CHF 90–100/yr) — a cheap way to meet people in a remote-heavy org.

Anti-money-laundering — the essentials

From your mandatory AML compliance training (passed 87%). Compliance is one of the regulatory pillars the company must uphold, and it touches your ITSCM role. Full notes in Guide 6.

Off-limits / high-risk business

• Private individuals, especially PEPs (politically exposed persons) — off-focus; exceptional cases need the AML office immediately.
• Cash — essentially forbidden; the classic laundering red flag.
• Domiciliary / shell companies — elevated risk; escalate before signing, don’t self-clear.

The reporting chain (two separate steps)

You never report to MROS or the police yourself. Failing to report = a criminal investigation AND warning/dismissal.

Due diligence — before the contract, always

Contracting partner ≠ beneficial owner (identify both). A company is verified with an official Commercial Register Extract — never a website printscreen or an email from management.

The information ban

Once a suspicion exists, you may tell no one — not the customer, not colleagues, not third parties (“no tipping off”). Only the AML office. It applies inside Swiss Life too.

Org, Jira know-how & the CTO view of Fit 28

From your KT with Roland and the Fit 28 CTO department town hall. Full notes in Guide 7.

Fit 28 — the four IT pillars (with dates)

Jira / Xray — Roland’s hands-on tips

• QA TM Dashboard = your daily start. Bookmark AND star it.
• Dashboards are at the BOTTOM of the search, not the top (the top is for issues) — the classic newcomer trap.
• Recent = last ~5 opened; Starred = your pinned favourites (max ~5) in the side panel.
• New dashboard rights aren’t instant — boards refresh ~every 15 min, but you can manually refresh each gadget.
• Hover the issue icon to see its type (e.g. Xray Test Execution). Projects differ: SCDU = SimCorp upgrades, ITSM = service management.
• Notifications are mostly manual — system only auto-mails watcher/assignee/reporter; you inform stakeholders directly. Roland: watch/CC yourself generously.
• Test loop: Test Execution → Story → Test Cases. Stay behind the tester (e.g. [a colleague], DWH failover, deadline 25 Sept); watch status go Blocked/Warning → Play; then document, close, inform.
• "Ask Revo" (top) = an AI assistant — useful, but never the final word (per your AML training).

The org & a tip

a colleague Steinmetz heads Securities IT; the Securities-IT lead leads the technical SimCorp side, a colleague Front Office & Accounting; Data Warehouse team includes [a colleague]. A new Portugal team (~June 2026) sits under Steinmetz. Tool tip: click a person → their org tree appears below. Your plan (Roland-approved): map Application Owners from your predecessor’s Excel and build first contact over Zürich lunches.

A real DR test, the Shared IT town hall & closing a ticket

Your first live disaster-recovery case, a second Fit 28 town hall, and end-to-end Jira ticket handling. Full notes in Guide 8.

A real DR test in practice (with the Terminal owner [a colleague])

the Terminal owner [a colleague] is the BA for SFTC (a Treasury app). Keep two events apart:

The Shared IT town hall — the clearest reassurance yet

• “No staff reductions in Shared IT, and no moves of roles” if the planned Fit measures materialise — because past internalisations (DWP, Cloud ops) already cover the savings.
• Honest nuance: strong H1 results lean heavily on one-off real-estate deals (not sustainable) — hence transform now, from strength.
• Shared IT leads several digital bricks (workflow orchestration, document management, AI factory, app engineering platform), integrates acquisitions, and enables private-assets collaboration — all while resilience & cyber security stay paramount (“reputation is our biggest asset” — your territory).

Jira / Xray — closing a ticket end-to-end (Roland)

Worked example: a Solution Bundle (a patch fixing production defects from the big release).

• Flow: patch tested on test env (17 tests, all passed) → close the bag (mark complete) → inform stakeholders directly → goes to production Saturday.
• Notifications are mostly manual: the system auto-mails only the Watcher, assignee & Reporter — everyone else you inform yourself. Events configurable in Space Settings (admin rights). Roland: watch/CC yourself generously.
• Test-execution loop: Test Execution → Story → Test Cases. Stay behind the tester ([a colleague], DWH failover, deadline 25 Sept); watch status Blocked/Warning → Play; then document, close, inform. Case types e.g. Restore on the Same Stage, Failover.
• Scope (Roland’s rule): “we don’t develop anything.” With Stories you only flag if one has no Test Case — no story-point estimation / Priority Poker. Your job is testing & documentation, not building.

The Test Activity Plan — where you actually work

The single most important document in your job: one Excel workbook that is your DORA register, CIF list, country-notification map, contact list, test schedule, budget and resource plan all at once. Full breakdown (names removed) in Guide 9.

Sheet 1 — the register & schedule (your daily driver)

Each row = a CIF app or underlying ICT, with category, vendor, which countries use it (who to inform), owner, technical contact + deputy, CIS, and tier — then a quarterly grid (2024→2028) of what’s tested when.

Golden rule on the sheet: every CIF must be tested at least once within 3 years.

Group 9 rows = your yearly exercises: InventX DC failover/recovery, FRCP walkthrough (all CIFs), ICT-EO tabletop simulation — the backbone of the Nov–Dec cycle.

Standing in for Reto, and the test you’ll run most

Two things you must be able to do: chair the Change board when Reto’s off, and run a theoretical ITSCM test on an IRRP. Full notes in Guide 10.

Deputising at the CAB

The CAB is a weekly meeting where planned changes are presented and approved/vetoed. The subtle part: until end 2027 SLAM still shares some infrastructure with the Swiss Life group, so their changes can hit us — which is why you watch the group’s board too.

The theoretical test — the one you’ll do most

It is not a recovery — you never touch UAT/production. You verify the IRRP is current. Four checks:

Where it lives: the IRRP (one per app) sits in the Recovery Documentation library (Confluence/Teams), alongside the FRCP. The Excel plan holds only the ticket link — detail is in the IRRP + Jira ticket.

Improvements worth noting (for later)

• The theoretical test is a fixed 4-point checklist — ideal to standardise as one reusable Xray template.
• Contact-verification is the recurring core — a periodic “confirm your contacts” Control Procedure would keep IRRPs fresh between tests.
• Its status could flow to the plan automatically (the v2 concept) — the theoretical test is the easiest process to modernise first, because it’s a checklist, not a live recovery.

Run the Shared-IT CAB like Reto

You’ll take this over soon and lead it when Reto’s away. This is the confirmed agenda from the official minutes turned into a script. Full version + “before you lead it” checklist in Guide 11.

The confirmed 5-block agenda

Delivering Reto’s part in the infra call

A weekly Securities-IT infrastructure coordination call. the Securities-IT lead leads it — you don’t chair. But when Reto’s off, you deliver Reto’s part. Full detail + prep checklist in Guide 12.

What it covers (recurring items)

• Cloud config / SL-AG ownership changes (email asks everyone to check the change list for issues)
• Community-Cloud move at Inventx (next batch of machines)
• Router & switch upgrades from the provider
• IT Security Services — upcoming changes (often none)
• Stream monitoring / restarts · a mid-month software update (Oracle piece not to be cancelled)
• DB → Cloud upload that stalled — open item to clarify

🎯 Reto’s part — the piece you deliver

His contribution is the ITSCM / testing & continuity view of the infra on the table — how these changes intersect our tests and recovery, and what we’re testing when. Come with five things:

Your three meetings, straight

You chair one, harvest one, contribute a specific part to one. confirm the italic ticket specifics with Reto/the Securities-IT lead — the transcript was noisy.

The Securities board — the live items to watch

The Tuesday Securities-IT CAB. Same 5-block agenda as the Shared-IT CAB (section 23) — this covers the current, live items and where they touch your ITSCM work. Full detail in Guide 13.

Other live items & your ITSCM angle

confirm the budget numbers, dates and names with Reto — the transcript was noisy.

Your weekly rhythm — and the security test

Setting up the two relationships that shape your week, a real test walkthrough, and the physical-security exam. Full detail in Guide 14; ready-to-use OneNote templates in 13_OneNote_Templates/.

🎯 The SFTC / S-Tunnel test call (a real example)

• S-Tunnel is a VPN-type component for the FIX connections (Bloomberg MM, TSOX/EMSX, MAP/Make…). The test = delete all test config, then freshly re-install with settings & certificates — and that re-install covers all FIX connections at once (two flies, one swat).
• Ticket cleanup pattern: the vague 450 “Service Recovery Test” was cancelled; the real steps live in ITSCM-424, linked under the parent. Documented + reusable.
• Theoretical vs practical: kept theoretical for now (the 4-point doc check). If you add the practical, you must play through every case + evidence it. Contract/confidentiality checks that aren’t ours stay out (that’s the Terminal owner’s topic).

📋 Security School — the exam content

Mandatory physical-security training + a short online test. Memorise the numbers:

Four topics: Fire (rescue self → others → close doors → small fires only; assembly point = car park by the Palme, take your notebook) · Medical (unconscious → 144 + 6220; “think then act”; AEDs on the ground floor) · Access / clear desk (lock documents, badge, cameras record, lost badge → replacement patch) · Intruder (lock your office, wait for police/security instructions). Complete the emailed online training + test.

The practical playbook

The small, hard-won habits that keep you clean — not in any official doc, but the difference between looking on top of it and always catching up. Full living list in Guide 15; add to it as you learn.

The confirmation — and where the division heads

A team meeting with Reto locked in the Fit 28 picture and sketched the years ahead. Full detail in Guide 16; a team-meeting tracker in 13_OneNote_Templates/.

Fit 28 — the confirmed shape

• ~CHF 100M savings across the division, each area allocated a share; ~300 headcount mainly via natural attrition / not-refilling.
• Still open: exactly how a “reduction” is measured, and when it’s concrete for individuals — expect clarity around the January PMO kick-off.
• Reto’s read: doing this from strength beats reacting later; and communication will get more concrete & initiative-level (July timing left people stewing).

Where the division heads (your job grows with it)

The four core principles (security test prep)

From the mandatory privileged-access training. Full test prep in Guide 17. These tie straight to your ITSCM world (four-eyes approvals, audit trails, least-privilege on tests).

🎯 The four principles

The insight that makes Jira click

A deep session with Roland: the definitive Epic-vs-Story model, your v2 idea validated, and a new task from Reto. Full detail in Guide 18; the everyday reference in 13_OneNote_Templates/DAILY_DRIVER.md.

Story per line, Epic per cycle

The rulebook confirmed live, plus the CSV import shown working in UAT. Full detail in Guide 19; the file is Jira_Import_ITSCM_TestPlan.csv.

Test Design vs Test Execution (the classic confusion)

Hunting for evidence and only seeing steps? You’re in the wrong view — open the Execution.

The CSV — 147 rows, 100% from the Excel

15 Epics (one per cycle) + 132 Stories (one per app per scheduled test), using the required template: Epic-Link · Issue Type · Summary · Description · Acceptance Criteria · Reporter · Assignee · Priority · Labels · Labels.

• Each Story’s Description carries every register field — service group, DORA #, categorization, org, infrastructure, vendor, CMDB, CIF, tier, entities using it, and all four responsibility roles.
• Acceptance Criteria mirrors the real 4-point check + evidence in the Execution view + inform the affected entities.
• Priority derived from Tier (1 → Highest, 1-light/2 → High, 3 → Medium). Labels: ITSCM + cycle/tier.

Your probation goals

The Zielvereinbarung set in the weekly 1-on-1 — three pillars you’re measured on. Review + next-year goal-setting: January / February. Full detail in Guide 20; live tracker in 13_OneNote_Templates/MY_3_PILLARS.html.

Three moments that showed the right instincts

• The budget reflex worked — a provider report (~CHF 7,150) needed because earlier results didn’t meet regulator expectations: you checked with a colleague, then took it to your manager rather than deciding.
• You challenged a thin closure — a DR ticket closed as “not necessary” with a copy-paste justification. You pushed for the reason in writing: “if there’s an audit tomorrow, this has to be documented.”
• You handled a colleague’s call — took the SFTC discussion on his behalf and tracked both dates moving to October.

When an owner says no

Your first real pushback — and the coaching that followed. This is the most important principle of the role. Full detail in Guide 23.

Your three jobs (and only these three)

The rest of the coaching

• “Wir sind doch nicht im Kindergarten” — owners are professionals; they must grasp that the regulator requires this and we must prove it.
• Evidence is non-negotiable — ~25% don’t attach it; the answer is to send it straight back. In Jira, Tester & Reporter are the recorded responsible parties.
• “Du musst ein bisschen egoistisch sein” — not inconsiderate, but don’t absorb others’ constraints as your own problem. Keep your eye on your deliverable.
• Don’t escalate in the first call. Offering help first got the same result — a concrete new date — without burning the relationship.

The dress rehearsal — and the rule you must not break

The annual Year-End Closing Test, a critical Jira warning, and some honest perspective on ramp-up. Full detail in Guide 24.

The Year-End Closing Test (“Generalprobe”)

Scope & a gap worth noting: it covers SimCorp + Data Warehouse only. Not the other applications — simply because accounting asked for that one and nobody requested the rest. Reto keeps an annual planning calendar with activities and freeze periods — ask for it.

Two answers you needed

How to record status in the plan, and the stance on “we have no resources.” Full detail in Guide 25.

🎨 The Excel status rule

The rule: as soon as the Epic goes In Progress, the Excel entry turns orange — don’t wait for every child test. You’ve begun running it, and that’s what the plan tracks; the per-test detail lives in Jira.

Why tests rotate: theoretical → practical → recovery

Not arbitrary escalation — a deliberate rotation. You do a theoretical test one cycle, then at some point a practical one, then a recovery — because the owner has to actually participate. A paper check alone never proves recovery works.

A useful read: the owner likely already knew the reason but preferred not to say it. Not everything unsaid is ignorance. · And the standing instruction: document it — the written trace is what makes it auditable.

How to lead an audit walkthrough

“DORA: ICT Incident Management & Operational Resilience Testing” — audited by Internal Audit (not the regulator; they check whether we’d pass). Full prep in Guide 26; one-page sheet in DORA_AUDIT_CHEAT_SHEET.md.

The 4 agenda points — one sentence each

Leading the next one

Open (restate the 4 points) → per topic: process → document → live example → known limits → questions → close: read back every follow-up with owner + date, confirm by email the same day.

How the change boards are really run

The practitioner’s view on top of the official agenda (section 23): preparation, run order, and what the moderator deliberately stays out of. Full detail in Guide 27.

Preparation — the real work happens before

• Filter by planned start date in the group ticketing system → copy title, description & contacts into our overview. New items in yellow.
• “When in doubt, include it” — showing something irrelevant costs nothing; missing something relevant costs a lot.
• Check every date against the freeze periods (e.g. rebalancing) — the day before is fine, during it gets rejected.

Shared IT run order — target 15 minutes (“zack-zack”)

Security IT (afternoon): same opening; the core is the list of user stories (each owner speaks, then approve). Problem management only in even calendar weeks — check the week number first.

🎙️ Tip: Teams transcription (announced to all, no video, AI summary) frees you from note-taking while chairing — always announce it and follow policy.

Shared IT CAB — the run sheet

Two styles compared — one run fast, one run with more discussion — and the version that takes the best of each. Full script in Guide 28.

Your version: the fast style’s preparation and pace + the structured style’s structure and your ITSCM slot.

Before the meeting

• Monday: harvest the group CAB into our infrastructure-changes page (new items in yellow) — when you chair, this is yours.
• Note what each ticket says about impact — you relay it, you don’t judge it.
• Tuesday: every link open in its own tab, already at the right date. Join a minute early; start the transcription.

Key lines

Why a link is not proof

An owner passed two tests with a beautiful script — documented in the wrong place. The lesson is one of the most important you’ll get. Full detail in Guide 29.

Three reasons a link fails

🎯 Meeting craft — cutting discussions off

“Die Leute reden und reden und es bringt nichts” — and the honest part: “da sind wir auch selber schuld, die Leute, die das moderieren.” A meeting that runs long is a chairing problem.

• Force the decision: “What’s the decision here? What’s the essence?”
• Hand it back with a date: “If you can’t decide now, take it away and tell me by when.”
• Offer the bilateral: “Let’s take these two points between us — send me your feedback.”

And for technical questions that aren’t yours: “Sorry, I don’t have that know-how — could someone jump in?” That’s the right answer for a moderator, not a weakness.

🛠️ Teams toolkit (from the training)

Co-organizer (almost all organizer rights — exactly what to request) · Green Room (align & test before anyone sees) · auto-shorten meetings (30→25, 60→50) · agenda in the invite (helps participants and Copilot) · “Follow event” · scheduling poll · room search by site abbreviation + underscore · transcript via Calendar → meeting → Meeting Recap.

⚠️ Added ad-hoc to a meeting? You may have no chat or transcript access — get added to the series. And note: deleting an item doesn’t always un-send its notification.

Your rulebook — and your first SME review

A mandatory Technical Standard owned by the CISO Office, built on CIS Control 11 and DORA. Full teaching version in Guide 30; draft comments in REVIEW_v2_Complete_Analysis.md.

Vocabulary

⭐ The six gaps that ARE yours

1. “Central test program” never defined or owned — referenced 3×. If it’s the Test Activity Plan, say so, or every obligation lands on ITSCM by default. Strongest point.
2. “Signed test report” undefined — required in every row; plus business-owner sign-off is a new process step.
3. The two tables don’t match — backup schedule has 10 categories, the test table 7. Four have no test row at all.
4. SaaS row has no success criterion — every other row does.
5. No failure path — evidence for success is defined; remediation / re-test / escalation isn’t. Auditors always ask.
6. Roles & independence not stated — who executes, coordinates, verifies. (Verify the DORA independence point yourself before citing.)

Preparing evidence vs. owning it

You transferred a colleague’s test documentation into the execution — carefully and well. The process correction that followed is worth more than the work. Full detail in Guide 31.

The fix — three steps, one second of their time

📋 The Testboard report template (being standardised)

Four blocks: Progress & KPIs · Execution (requirements still uncovered) · Defects (with their development over the cycle) · Decisions & next agenda.

Design principles worth copying: readability first · an explicit follow-up action visible at a glance · a call-to-action hyperlink straight to what the person must do · snapshots, not real-time — a dated screenshot fixing the state at reporting time.

That last one is the same logic as audit evidence: a fixed record beats a live view when you need to prove what was true at a moment in time.

The weekly release run

A new process area, separate from ITSCM testing — and one you’ll run yourself next week under four eyes. Full detail in Guide 32.

Workflow: In Progress → Implementation → Unit Test → Ready for Transport → Transported to Production. Releases grouped by Fix Version.

Change types

Normal — full workflow, board approval before implementation · Emergency — Emergency CAB, transported directly, deployment date documented · Pre-approved — transportable any time, owner carries responsibility.

⚠️ Never delete a normal change and re-create it as an emergency to bypass the process. · Retroactive entries are possible but only as a documented exception — the rule stands: no implementation without prior approval.

The Friday release — end to end

The process you’re taking over. Full handover in the Runbook doc (3 tabs); learning-path version in Guide 33.

The day

What a realistic end of day looks like

56 Closed · 7 Sanity Check · 1 still at Transport to Production (chased individually) · window count down 66 → 64. Chasing was two mails plus a few individual messages — and several people came of their own accord to say their change could be dropped.