--- title: "Vulnerability Disclosure Policy" id: "754" type: "page" slug: "security-policy" published_at: "2026-08-14T15:29:26+00:00" modified_at: "2026-08-14T15:32:26+00:00" url: "https://caritas-netzwerk-it.de/en/security-policy/" markdown_url: "https://caritas-netzwerk-it.de/en/security-policy.md" excerpt: "Deutsche Fassung dieser Seite Version 1.0 · 14 August 2026 This policy is referenced from our security.txt in accordance with RFC 9116. Our commitment Caritas-Netzwerk IT e. V. is an association in which Catholic social-welfare organisations in Germany organise their..." --- [Deutsche Fassung dieser Seite](/security-policy/) **Version 1.0 · 14 August 2026** This policy is referenced from our [security.txt](/.well-known/security.txt) in accordance with RFC 9116. ## Our commitment Caritas-Netzwerk IT e. V. is an association in which Catholic social-welfare organisations in Germany organise their IT together. Security is not a side topic for us — our members rely on us for exactly this expertise. We therefore want to hear about weaknesses in our own systems, and we want the people who find them to know in advance how we will treat them. If you have found a security vulnerability in one of the systems listed below, please report it to us. We will take your report seriously, keep you informed, and we will not take legal action against you if you followed this policy. We do not operate a paid bug bounty programme. Please read the section on recognition before you invest significant time. ## Scope ### In scope Systems and services operated by the association under its own responsibility: - **Website:**`caritas-netzwerk-it.de` and all of its subdomains, including the members‘ area - **Email infrastructure** of the domain `caritas-netzwerk-it.de`, including its DNS configuration - **Microsoft 365 tenant** of the association - **Atlassian Cloud** (Jira, Confluence) of the association - Any other service that is publicly reachable and clearly identifiable as being operated by Caritas-Netzwerk IT e. V. ### Configuration versus product For the cloud services above, our responsibility ends where the product begins. - **Report to us:** anything we configured, published or exposed — misconfigured sharing permissions, publicly readable content that should be internal, weaknesses in our DNS records, exposed credentials belonging to us. - **Report to the vendor:** vulnerabilities in the underlying product itself. Microsoft and Atlassian each run their own vulnerability programmes, and they are the only parties who can fix such issues. If you are unsure which case applies, send it to us and say so — we would rather receive a report that turns out to belong elsewhere than miss one. ### Out of scope - **Systems operated by our member organisations.** See the next section. - Third-party platforms on which the association merely holds an account (for example social networks), where the finding concerns the platform itself. - Websites that link to us or that we link to, but which we do not operate. - Physical facilities, offices and staff of the association. ## Systems belonging to our member organisations More than 150 legally independent Catholic social-welfare organisations are members of our association. **We do not operate their IT systems**, we have no access to them, and we cannot fix vulnerabilities there. Reports about their websites, portals or infrastructure are therefore out of scope for this policy. Please report such findings directly to the organisation concerned — most publish their own contact details in their legal notice (“Impressum”). **If you cannot reach anyone there, write to us anyway.** We will not assess the finding ourselves, but we will pass your report to the right people and put you in touch. Please state clearly in your message that the report concerns a member organisation and which one. Note that in this case the response times below do not apply — we depend on a third party. ## How to report Send your report by email to [info@caritas-netzwerk-it.de](mailto:info@caritas-netzwerk-it.de?subject=Security) with the subject line **“Security”**. The address is monitored by the association’s office during regular business hours. Reports are forwarded internally to the people responsible for the affected system. We currently do **not** offer an encrypted reporting channel. If your report contains information too sensitive for unencrypted email, please send us a short message without technical detail and we will agree on a secure channel with you. Please write in **German or English**. ## What your report should contain The more precisely we can reproduce a finding, the faster it gets fixed. Please include: - The **affected system**, URL or endpoint - A **description of the vulnerability** and its technical cause, as far as you can determine it - **Step-by-step instructions to reproduce** it - The **impact** you consider realistic — what could an attacker actually achieve? - Screenshots, log excerpts, request/response pairs or proof-of-concept code where helpful - Whether you intend to publish the finding, and on what timeline - How you would like to be credited, if at all Please tell us if you have shared the finding with anyone else, or if you believe it is already being exploited. ## Rules of engagement We ask you to keep your testing proportionate. Specifically, please do **not**: - Run **denial-of-service or load tests**, or otherwise degrade the availability of our services - Use **social engineering** against our staff, our members or our service providers — no phishing, no pretexting, no telephone attacks - Attempt **physical access** to offices, buildings or equipment - Access, copy, modify or delete **data that is not your own**. If you encounter personal data, stop immediately, do not save it, and tell us in your report what you saw - **Modify or destroy** anything on our systems, including creating unnecessary accounts, defacing content or leaving files behind - Deploy **malware, backdoors or persistence mechanisms** of any kind - Continue testing **beyond what is necessary** to demonstrate the vulnerability. A single proof is enough; there is no need to determine how far the access reaches Please use your own test accounts wherever possible, and use a recognisable identifier (for example in the user agent or in submitted form data) so that we can distinguish your testing from a real attack in our logs. ## What you can expect from us - **Acknowledgement of receipt:** within **5 working days** - **Initial assessment** — whether we consider it a vulnerability, and how severe: within **15 working days** - **Status updates:** at reasonable intervals until the issue is resolved or we tell you we will not act on it - **Notification of the fix:** as soon as the issue is closed Working days are Monday to Friday, excluding public holidays in Hesse, Germany. We are a small team. These periods are deliberately chosen so that we can meet them even during holiday seasons — not because a report would sit untouched for that long. Urgent, actively exploited issues will be handled far more quickly. If we decide not to act on a finding, we will tell you why. ## Coordinated disclosure We ask you to give us **90 days** from the date of your report before publishing any details. If we fix the issue sooner, you are welcome to publish sooner — just let us know. If a fix takes longer, we will tell you why and propose a new date; we will not use the process to delay publication indefinitely. We do not require you to keep the finding secret forever, and we will not ask you to sign a non-disclosure agreement as a condition for us fixing our own systems. ## What we do not treat as a vulnerability The following are, on their own and without a demonstrated concrete impact, outside this policy. We will usually close such reports with a short reply: - Missing or “weak” HTTP security headers without a working exploit - Raw output of automated scanners without verification or proof of exploitability - Findings derived solely from a software version number, without a demonstration that the instance is actually affected - Self-XSS, i.e. attacks requiring the victim to paste code into their own browser - Missing rate limiting or missing account lockout, without demonstrated impact - Clickjacking on pages that carry no state-changing action - Recommendations regarding SPF, DKIM or DMARC configuration where no actual spoofing has been demonstrated - Missing certificate pinning, weak TLS cipher suites without a practical attack - Publicly available information that is published deliberately, such as staff names and contact details in our legal notice - Reports about outdated or “insecure” third-party libraries where no vulnerable code path is reachable - Best-practice advice without a security finding attached If you believe one of these does have a real impact in our specific setup, show us — that is exactly what turns it into a valid report. ## Recognition — and what we do not pay for **We do not operate a bug bounty programme and we do not pay for vulnerability reports.** As a non-profit association funded by membership fees, we spend our resources on our members‘ security. What we do offer: if you report a valid vulnerability, we will thank you, and on request we will **name you publicly** on our acknowledgements page once the issue is fixed. Tell us in your report whether you want to be named, and under which name or handle. You may also ask us to stay anonymous. **Reports without evidence.** We receive automated and AI-generated messages that describe generic weaknesses without any verification. We do not process reports that lack reproducible steps and a demonstrated impact. **Unsolicited invoices.** We will not pay invoices, “finder’s fees” or “consulting fees” that accompany an unsolicited report. A report submitted with a payment demand attached will be treated as what it is, and we reserve the right to respond accordingly. ## Safe harbour If you follow this policy, we consider your research to be **authorised** and: - We will **not initiate legal proceedings** against you — neither criminal complaints nor civil claims — in connection with your research or your report. - We will **not report you to law enforcement** for the research itself, and if a third party does, we will confirm on request that your activity was authorised under this policy. - We will treat your report as an act of assistance, not as an attack. This assurance is subject to the following: - It applies only to research **within the scope defined above** and within the **rules of engagement**. - It covers only claims that we ourselves could raise. We cannot waive the rights of third parties, and it does not override statutory obligations that may apply to us. - It does not cover the misuse of data you obtained, extortion, or the sale or passing on of findings to third parties for exploitation. If you are uncertain whether a planned test is covered, ask us first. We would rather answer a question in advance than discuss it afterwards. ## Handling of your personal data We process the data in your report — including your email address and any name you give us — solely for the purpose of assessing and fixing the reported issue and for communicating with you about it. Details are set out in our [privacy policy](/datenschutz/) . If you wish to remain anonymous, you may report from an anonymous email address. We will not attempt to identify you. ## Changes to this policy This policy may be updated. The version and date at the top of this page always indicate the current status. Material changes do not apply retroactively to reports already submitted — the version in force at the time of your report governs. ## Thank you Reporting a vulnerability instead of exploiting or selling it is a decision in favour of everyone who relies on these systems. In our case that includes social welfare organisations and the people they serve. We appreciate it.