* layout / typos / favicon

Author: olexandrbig

.gitignore

@@ -127,3 +127,5 @@ dmypy.json
 
 # Pyre type checker
 .pyre/
+.idea/
+.claude/

CHANGELOG.md

@@ -1,4 +1,4 @@
-# SOLUTION NAME
+# TrustSource User's Guidance to SSRM
 
 ## Changelog
 
@@ -7,8 +7,13 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## 0.1.0 22-10-23
+## 0.2.0 2026-03-26
+
+### Fixed
+* layout / typos / favicon
 
-### Added
 
-* Changelog - a file that tracks changes. Primarily for external audiences
+## 0.1.0 2023-10-22
+
+### Added
+* Changelog – a file that tracks changes. Primarily for external audiences

CLAUDE.md

@@ -0,0 +1,42 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Project Overview
+
+This is the **TrustSource Shared Security Responsibility Model (SSRM)** — a documentation-only site describing the distribution of security responsibilities between TrustSource (provider) and its customers. It is built with MkDocs Material and deployed to GitHub Pages.
+
+Site URL: https://trustsource.github.io/SSRM
+
+## Build & Serve Commands
+
+```bash
+# Install dependencies
+pip install zensical
+
+# Local development server
+zensical serve
+
+# Build static site (output goes to ./site)
+zensical build --clean
+```
+
+The project uses **Zensical** (an MkDocs-based tool) — not plain `mkdocs`. All build/serve commands use `zensical` instead of `mkdocs`.
+
+## CI/CD
+
+Pushes to `main` trigger `.github/workflows/ci.yml`, which builds with `zensical build --clean` and deploys to GitHub Pages via `actions/deploy-pages`.
+
+## Repository Structure
+
+- `mkdocs.yml` — Site configuration (theme, navigation, analytics, consent)
+- `docs/` — All Markdown content pages (index.md, accessSecurity.md, dataIntegrity.md, artefactIntegrity.md, eos.md)
+- `docs/assets/` — Images, CSS, and JS assets
+- `.nojekyll` — Prevents GitHub Pages from processing with Jekyll
+
+## Content Notes
+
+- The site uses Material for MkDocs theme with light/dark mode toggle
+- Google Fonts are disabled (`font: false`) for data privacy compliance
+- Google Analytics is configured but uses a placeholder property ID (`G-xxx`)
+- Content is licensed under CC-BY-SA-4.0

README.md

@@ -1,7 +1,7 @@
 # TrustSource User's Guidance to SSRM
 
-This repo contains a detailed description of the measures, responsibilities and organisations undertaken to ensure a secure and uninterrupted operation of TrustSource solution. Besides explaining what TrustSource does, it also outlines the reponsibilities of the TrustSource customer and indicates where to find additional support to cope with these challenges.
+This repo contains a detailed description of the measures, responsibilities and organizations undertaken to ensure a secure and uninterrupted operation of TrustSource solution. Besides explaining what TrustSource does, it also outlines the responsibilities of the TrustSource customer and indicates where to find additional support to cope with these challenges.
 
-The guide itself is continuously updated to keep pace with the change. However, it will carry a version number and older versions will be kept for later reference. To get an idea of the changes and updates a CHANGELOG is maintained.
+The guide itself is continuously updated to keep pace with the change. However, it will carry a version number and older versions will be kept for later reference. To get an idea of the changes and updates, a CHANGELOG is maintained.
 
 This solution is built on top of MKDocs by [Martin Donath](https://github.com/squidfunk).

docs/accessSecurity.md

@@ -1,22 +1,22 @@
 # Access Security
 
-The solution implements access seurity. It is not possible to access any data or any information from the system without an authenticated request. To ensure this TrustSource uses a proxy, which is requesting and verifying every request, before executing it. There are two possible Authentication providers:
+The solution implements access security. It is not possible to access any data or any information from the system without an authenticated request. To ensure this TrustSource uses a proxy, which is requesting and verifying every request, before executing it. There are two possible Authentication providers:
 - TrustSource
 - External Identity Provider
 
 ## TrustSource as Identity Provider
 
-To access TrustSource, a username / password combination has to be provided. To keep this confidential is a key repsonsibility of every user. 
+To access TrustSource, a username / password combination has to be provided. To keep this confidential is a key responsibility of every user. 
 
-We recommend using a 3rd party identity provider that supports multi factor authenticiation. 
+We recommend using a 3rd party identity provider that supports multi factor authentication. 
 
 ### Adding new users
 
 While using TrustSource as the Identity Provider you have the option to invite users to join your account. These users are allowed to be from any organisation. It is in the responsibility of the account owner (role Account Admins) to invite only trustworthy users. 
 
-New users will receive an invitation by email with a link they need to activate their access. in the next step, they require to set a password. A forgotten password can be reset anytime using the forgotten password link. Thus, if a user from an insecure domain is invited, a malicious suspect might take over the mail account and use the reset function to gain access.
+New users will receive an invitation by email with a link they need to activate their access. In the next step, they require to set a password. A forgotten password can be reset anytime using the forgotten password link. Thus, if a user from an insecure domain is invited, a malicious suspect might take over the mail account and use the reset function to gain access.
 
-However, it is also in the repsonsibility of the account owner to remove access for users when it is not longer required.
+However, it is also in the responsibility of the account owner to remove access for users when it is no longer required.
 
 ### Assigning Roles
 
@@ -30,26 +30,26 @@ Deleting the user will close the account. No more access will be possible for th
 
 ## 3rd Party Identity Provider
 
-Depending on your subscription, you may want to add an external Identity Provider. This could be either your corporate Active Directory, Github or Apple. The benefit of these providers is for example the support for One Time Password (OTP) authentication, but also more comfort in managing users. Given a user leaves the company, your HR will take care to remove him from the corproate directory. If you use this as Identity Provider, the user will immediately loose access to TrustSource as well. If you decide for manual user management, you will have to provide a routine - either manual or automated - to ensure the removal in TrustSource will take place in time. 
+Depending on your subscription, you may want to add an external Identity Provider. This could be either your corporate Active Directory, Github or Apple. The benefit of these providers is for example the support for One Time Password (OTP) authentication, but also more comfort in managing users. Given a user leaves the company, your HR will take care to remove him from the corporate directory. If you use this as Identity Provider, the user will immediately lose access to TrustSource as well. If you decide for manual user management, you will have to provide a routine - either manual or automated - to ensure the removal in TrustSource will take place in time. 
 
-In addition these providers may also provide an OID token containing claims concerning their roles in TrustSource. In Active Directory this typically is organized through memebership of Security Groups. Thus you would assign every user to a set of security groups, according to the roles they shall have in TrustSource ([see role mapping](https://support.trustsource.io)).
+In addition these providers may also provide an OID token containing claims concerning their roles in TrustSource. In Active Directory this typically is organized through membership of Security Groups. Thus you would assign every user to a set of security groups, according to the roles they shall have in TrustSource ([see role mapping](https://support.trustsource.io/hc/en-us/articles/28809165865490-TrustSource-Roles)).
 
-To setup a 3rd party provider, you will require a user with the role "Account Admin". The first user creating an account automatically will own this a role. The role allows to invite/add new users - see [Account Admin Role](!https://support.trustsource.io/) in the online help - as well as arrange account settings. 
+To setup a 3rd party provider, you will require a user with the role "Account Admin". The first user creating an account automatically will own this role. The role allows to invite/add new users - see [Account Admin Role](https://support.trustsource.io/hc/en-us/articles/28809165865490-TrustSource-Roles) in the online help - as well as arrange account settings. 
 
 You may check your roles by hovering under your profile icon in the upper left corner. If the correct role is not set, you will need to contact an Account Admin to set the role. PLEASE NOTE: It is not possible to modify your own role! You will need to create a second Account Admin to change your role settings. 
 
-It is in **your repsonsibility** to assign roles with caution. If users have access or manipulate content within the application, TrustSource may not help. Our employees **do not have access to your account data**. However, all access will be logged in the access log, which is visible to Account Admin roles.  
+It is in **your responsibility** to assign roles with caution. If users have access or manipulate content within the application, TrustSource may not help. Our employees **do not have access to your account data**. However, all access will be logged in the access log, which is visible to Account Admin roles.  
 
-It is in **your responsibility** to setup and maintain the 3rd party provider connection details. If you need assistance, look at [our knowledge base](!https://support.trustsource.io/AD_integration) for help or contact support. 
+It is in **your responsibility** to setup and maintain the 3rd party provider connection details. If you need assistance, look at [our knowledge base](https://support.trustsource.io/hc/en-us/articles/28023076417554-Integration-of-3rd-party-Identity-Providers) for help or contact support. 
 
 ### Enforce 3rd party login
 
-If you setup a 3rd party provider, the authentictaion by the application still remains active. This will allow users that are available _only_ within TrustSource also to access the service. This might be a good solution in case you want external partners, which you do not want to manage / add to your internal AD to access the service. However, it bears also the risk, that these useres are not addressed with your user access management procedures, e.g. regular account review.
+If you setup a 3rd party provider, the authentication by the application still remains active. This will allow users that are available _only_ within TrustSource also to access the service. This might be a good solution in case you want external partners, which you do not want to manage / add to your internal AD to access the service. However, it bears also the risk, that these users are not addressed with your user access management procedures, e.g. regular account review.
 
-However, you may encforce that only accounts existing in your AD will be allowed to access the service. This will automatically prevent all users from loging in using the _local_ authentication. To do so, a known user with Account Admin role needs to create a ticket at TrustSource Support to initiated / deactivate IDM enforcement. PLEASE BE PREPARED: Our support will validate the origin of the request. 
+However, you may enforce that only accounts existing in your AD will be allowed to access the service. This will automatically prevent all users from logging in using the _local_ authentication. To do so, a known user with Account Admin role needs to create a ticket at TrustSource Support to initiate / deactivate IDM enforcement. PLEASE BE PREPARED: Our support will validate the origin of the request. 
 
 ### Configure SMTP
 
-TrustSource is configured to send all communications using `@trustsource.io` addresses. While using a 3rd party provider, you may prefer to use your own server for sending authentication and password reset emails. This can be done in the ACCOUNT ADMIN > SMTP section. As long as the server is not set up, all mails will go through the TrustSource mail server. See [our knowledge base](!https://support.trustsource.io/AD_integration) for more details on how to setup the integration.
+TrustSource is configured to send all communications using `@trustsource.io` addresses. While using a 3rd party provider, you may prefer to use your own server for sending authentication and password reset emails. This can be done in the ACCOUNT ADMIN > SMTP section. As long as the server is not set up, all mails will go through the TrustSource mail server. See [our knowledge base](https://support.trustsource.io/hc/en-us/articles/28023076417554-Integration-of-3rd-party-Identity-Providers) for more details on how to setup the integration.
 
 It is in **your responsibility** to setup and maintain this configuration.