SRC Security Research & Consulting GmbH: Gener­ation change at the top

After almost 25 years of successful management of the company by Gerd Cimiotti, the founda­tions are now being laid for a gener­a­tional change in the management of SRC — and thus for the next 25 years. With effect from August 1, 2024, Markus Schierack will be appointed to the management board of SRC Security Research & Consulting GmbH, Bonn.

As Managing Director of the payment trans­action institute VÖB-ZVD Processing GmbH (“Pagateq”), he has been respon­sible for business devel­opment, payment trans­ac­tions, finance and regulatory affairs, among other things. Markus Schierack brings many years of experience in strategic devel­opment and trans­for­mation in the area of payment trans­ac­tions to his new role. The corporate finance specialist has held various positions within the Deutsche Bank Group in recent years. Among other things, he actively supported various strategic M&A trans­for­mation projects of the bank’s private customer business in the Group Devel­opment department of Deutsche Postbank AG and at Deutsche Bank and positioned Pagateq as a BaFin ZAG-licensed payment service provider with its own identity within Deutsche Bank Group.

Gerd Cimiotti, who has been Managing Director of SRC since 2001, will actively support the gener­a­tional change and the handover to Markus Schierack until 2025 and will then retire from management: “One of the biggest challenges for medium-sized companies is the successful gener­a­tional change. At SRC, Markus Schierack is the next gener­ation to take on overall respon­si­bility for the company. I am very confident that Markus will not only lead SRC Security Research & Consulting GmbH into a good economic future, but will also keep the special values of our company alive,” explains Cimiotti.

The time frame was delib­er­ately set to allow for a gradual transition. The SRC share­holders’ meeting would like to take this oppor­tunity to thank Mr. Cimiotti for his trusting cooper­ation and his successful and tireless efforts to develop SRC into a leading IT security compe­tence center.

Markus Schierack already knows SRC very well from his role as Chairman of the SRC Share­holders’ Meeting and will now join the Management Board on August 1. Markus Schierack is looking forward to the challenge that he wants to master together with the employees at SRC: “My heart beats for the company and I have already had the oppor­tunity to get to know SRC well through my work as a repre­sen­tative of a share­holder of SRC Security Research & Consulting GmbH.”

The 43-year-old will be supported by Randolf Skerka, who will be respon­sible for SRC’s auditing business in the future. The current Head of Sales at SRC has been familiar with the company and the auditing business in particular for many years from various roles at SRC. “For me, teams with strong person­al­ities are always important in order to master upcoming challenges. I am therefore grateful to have Randolf Skerka at my side as an extremely experi­enced sparring partner,” says future Managing Director Markus Schierack.

About SRC Security Research & Consulting GmbH

SRC is the joint compe­tence center of the German banking industry for IT security. SRC was founded in 2000 with the support of the four credit industry publishers (Bank-Verlag GmbH, DG-Nexolution eG, S‑Payment GmbH and VÖB ZVD-Processing GmbH) and the leading associ­a­tions of the German credit industry repre­sented on the company’s advisory board (Bundesverband deutscher Banken e.V., Bundesverband der Deutschen Volks­banken und Raiffeisen­banken e.V., Bundesverband Öffentlicher Banken Deutsch­lands e.V., Deutscher Sparkassen- und Giroverband e.V.).

In April 2001, Gerd Cimiotti joined the company’s management and led the expansion of SRC into a leading IT security service provider in Europe. With more than 120 employees, SRC is not only one of the top addresses when it comes to technical innova­tions in payment, but SRC also offers a compre­hensive IT security and audit program to support customers all over the world.

The plan for the future is to further expand both business areas and take advantage of the emerging market oppor­tu­nities. The new management team led by Markus Schierack is an important prereq­uisite for this. The smooth transition in management from Gerd Cimiotti to Markus Schierack also ensures the necessary continuity.

SRC TeleTrusT

SRC joins the German IT Security Associ­ation (TeleTrusT)

SRC joined the German IT Security Associ­ation (TeleTrusT).

The Bundesverband IT-Sicherheit e.V. (TeleTrusT) is a compe­tence network comprising domestic and foreign members from industry, admin­is­tration, consulting and science as well as themat­i­cally related partner organisations.

Due to the perma­nently changing require­ments in the field of IT security, it is important for SRC that its experts regularly inform themselves about and exchange infor­mation on new neces­sities, techniques, processes and regulations.

TeleTrusT offers partic­u­larly good condi­tions for this, since in addition to the exchange of experts from the business world, contact is also estab­lished with politics and science.

SRC will contribute its wide-ranging expertise to the various working groups of TeleTrusT and thus give further signif­i­cance to the status of IT security in Germany and Europe.


Our December blog post on PCI DSS v4.0: Targeted Risk Analysis

The year is drawing to a close — and so is PCI DSS v3.2.1.

The PCI Security Standards Council (PCI SSC) has just published new documents on the new concept of “Targeted Risk Analysis” — so let’s take this as an oppor­tunity to take a closer look at the topic.

Targeted Risk Analysis – what is it?

PCI DSS v4.0 aims to enable more flexi­bility. One of the tools for this is the so-called “Targeted Risk Analysis”.

Targeted risk analyses differ from the company-wide risk analyses that were required in PCI DSS v3.2.1. They look at the specific risks for a very specific use case.

In PCI DSS v4.0, targeted risk analyses appear in two places:

  • Some require­ments of the standard call for targeted risk analyses to determine how often a certain regular control should be carried out.
  • In addition, the targeted risk analysis is part of the so-called “customized approach”, which allows you to implement a requirement in your own way, deviating from the literal implementation.

We will focus on the first case here, as we will dedicate a separate blog entry to the customized approach in February.

Where is it required?

A targeted risk analysis is required for the following PCI DSS requirements:

  • If an organi­zation has evaluated that system compo­nents are not commonly affected by malware and therefore do not require an anti-malware solution, then it must be checked at regular intervals to ensure that this is still the case. The frequency of these checks must be deter­mined in a targeted risk analysis.
  • If regular malware scans are used, their frequency must be deter­mined in a targeted risk analysis.
  • Often there are not only user accounts that are used by people, but also technical user accounts that are used by systems or appli­ca­tions. Their access rights must be checked regularly. The frequency of these checks must be deter­mined in a targeted risk analysis.
  • 8.6.3: Passwords for the afore­men­tioned technical user accounts must be protected. The frequency of password changes and password complexity must be deter­mined in a targeted risk analysis.
  • Payment devices (payment terminals) at the point of inter­action must be inspected regularly to detect tampering or substi­tution. The frequency and type of inspec­tions must be deter­mined in a targeted risk analysis.
  • Security-critical logs (security events and logs from systems that come into contact with account data, have security function­ality or are otherwise critical) must be reviewed at least daily in order to detect conspicuous activ­ities promptly. The frequency of the review for all other logs must be deter­mined in a specific risk analysis.
  • If high-risk or critical vulner­a­bil­ities are discovered during internal vulner­a­bility scans, they must be remedied. For lower-rated vulner­a­bil­ities, a targeted risk analysis must determine how these are to be addressed.
  • 11.6.1: E‑commerce payment pages must be regularly checked with a mechanism for detecting changes and tampering. This mechanism must be applied at least every seven days – otherwise a lower frequency must be justified with a targeted risk analysis.
  • The staff respon­sible for responding to security incidents must be trained in this. The frequency of this training must be deter­mined in a targeted risk analysis.

How to perform the targeted risk analysis

How the targeted risk analysis should be carried out is defined in requirement 12.3.1 of PCI DSS v4.0. This stipu­lates that the analysis must first identify at least the following points:

  • The assets to be protected. Of course, those always comprise the account data itself, but other assets such as systems or passwords can also be relevant.
  • The threats against which the corre­sponding PCI DSS requirement is intended to protect.
    To determine the corre­sponding threats, it is helpful to consult the “Customized Approach Objective” of the corre­sponding or higher-level PCI DSS requirement, as this objective often already specifies the threats against which the requirement is intended to protect.
  • Factors that contribute to the proba­bility of occur­rence and/or the impact of the realization of the afore­men­tioned threats.

Let’s get specific and take requirement as an example.

Here, both the account data and the payment devices are assets to be protected.

The “Customized Approach Objective” of the overar­ching requirement is that the tampering of devices, unautho­rized substi­tution of devices, or the attachment of skimming devices cannot be carried out without timely detection.

Typical threat scenarios would therefore be, for example

  • Attackers install skimming devices that read data input.
  • Attackers pretend to be service techni­cians or employees of the device provider and replace the payment device with a manip­u­lated payment device, which then reads account data and forwards it to the attackers.
  • Attackers steal a payment device on which data could be temporarily stored in the case of offline transactions.
  • Attackers manip­ulate the payment device in such a way that its security function­ality is weakened (e.g. encryption switched off).

Factors that can have an impact on the realization of these threats are, for example:

  • How easily acces­sible is the payment device to customers and third parties? Is it securely attached?
  • Is the payment device perma­nently attended / under supervision?
  • How well qualified and trained is the staff on site?
  • Are the payment device and the data in it protected against tampering, and is this proven by PCI PTS validation of the device and/or PCI P2PE validation of the entire solution?
  • How heavily frequented is the payment terminal? (This can have an influence on whether it is a partic­u­larly worth­while target for the attacker.)
  • Has the device provider provided recom­men­da­tions in their documen­tation on how frequently the devices should be checked?

The factors then result in the analysis that deter­mines how often an activity must be carried out in order to minimize the proba­bility of the threats occurring.

Factors and results of the targeted risk analysis must be documented.

At least every 12 months, each targeted risk analysis must be reviewed to check whether it is still applicable. If there have been changes in the factors or in their evalu­ation, the risk analysis must be updated accordingly.


As with every PCI DSS v4.0 requirement, the first thing worth looking at is the “Guidance” column to the right of the requirement in the standard itself.

In addition, the PCI SSC published three supporting documents on 28 November 2023:

And as always, you are welcome to ask SRC’s PCI DSS experts for support.


This is the last post on PCI DSS v4.0 for this year. We will continue our monthly blog series next year — you can look forward to the following topics then

  • January: Changes in e‑commerce: What’s changing in Self-Assessment Question­naire A?
  • February: Customized Approach
  • March: Changes in e‑commerce: Integrity protection of payment pages

Happy New Year, and take care!

Information security officers for credit institutions

PCI DSS v4.0 blog entry for October

PCI DSS 4.0 Evidence Guidelines

In this episode of our PCI DSS v4.0 blog, we explain assessors’ respon­si­bil­ities for providing evidence of their assessment findings, and how to prepare the provision of appro­priate evidence for PCI DSS v4.0 assessments.

Assessment process

During a PCI DSS assessment, assessors check the extent to which a company has imple­mented the PCI DSS requirements.

Typically, an assessment process includes the following steps:

  • Review of documents,
  • Review of system components/settings,
  • Review of processes,
  • Review of physical condi­tions, 
  • review of protocols/results, and
  • Inter­views with staff.

This does not change with the migration to PCI DSS v4.0.

Evidence require­ments

It usually remains hidden for the assessed company how an assessor makes notes and files evidence. We provide insight into the corre­sponding changes with PCI DSS v4.0.

With the new reporting template for PCI DSS v4.0 as well as with an update of the PCI DSS Program Guide for QSAs, the PCI SSC has now clarified that they require the assessor to file a corre­sponding evidence for each assessment step. The PCI SSC checks whether the assessor companies meet this by taking samples.

For documents, this is easy: the respective document itself is the required evidence. Regarding protocols/results, it is similar – here you just have to make sure that it is clear which system or process you are talking about.

 If you send a screenshot or file to an assessor as evidence, please make sure to include the infor­mation which system component and/or process it is about. When reviewing system components/settings, the assessor must take dedicated notes on the system and setting in question.

When reviewing processes or physical condi­tions, the respective condition must be described in detail and it must be shown what conclu­sions the assessor draws from the obser­vation. Similarly, in an interview, the assessor is expected to roughly write down the questions and answers.

Please give the assessor enough time to take notes during the assessment. In many cases, it can shorten the paperwork if the assessor is provided with copies or screen­shots or is allowed to take photos.

The PCI DSS v4.0 lists about 250 sub-items for the 12 main require­ments — the assessor will need a corre­spond­ingly large amount of evidence.

Retention require­ments

The PCI DSS Program Guide requires that all of the above evidence must be securely retained by the assessor company for at least three years and made available to the PCI SSC and associated companies upon request.

For reasons of privacy or confi­den­tiality, companies sometimes do not allow the assessor to take and file certain evidence. In this case, the PCI SSC stipu­lates that the evidence may be filed with the assessed company instead. The require­ments for retention period and avail­ability are the same in this case.

Since the oblig­a­tions to provide evidence have become greater with PCI DSS v4.0, this case is expected to occur more frequently in the future.

 If you expect that not all evidence may be passed on to the assessor, the best way to prepare yourself as an assessed company is by

  • preparing an audit-proof storage of the evidence for at least three years,
  • keeping a list of documents and evidence not handed over during the assessment,
  • preparing a written confir­mation for the assessor, in which you 
    • name the place of storage,
    • name the contact person whom the PCI SSC can contact if it wishes to inspect evidence, and
    • confirm audit-proof storage until a specific date at least three years in the future.

Dealing with deviations

How about evidence if the assessment did not immedi­ately demon­strate compliance with all require­ments, but devia­tions were found?

Planned devia­tions

In the simplest case is when you, as the assessed company, have already recog­nised in advance that you cannot fulfil a requirement or do not want to fulfil it in the specified way. In this case, you have already prepared documen­tation of a compen­sating control or a customised approach for the assessment. A PCI DSS expert can also help you with this — but it must not be the same individual who then assesses the implementation.

We will comment in detail on the Customised Approach in a later episode of our PCI DSS v4.0 blog.

In both cases, the assessor will review the evidence of your company’s Compen­sating Control or Customised Approach, ask questions if necessary, and then derive and implement appro­priate testing methods. The oblig­a­tions to collect evidence result from the respective assessment method.

Unplanned devia­tions — “INFI”

If unplanned devia­tions from PCI DSS require­ments occur during an assessment period, they must be remedied and the remedi­ation verified by the assessor. This was already the case in PCI DSS v3.2.1.

Additionally, PCI DSS v4.0 additionally explicitly requires that the cause for the occur­rence of the deviation is identified and that processes are imple­mented to prevent a recur­rence of such a deviation. Only if this is the case, the assessor can still consider the requirement as in place.

All devia­tions, their causes, corrective and preventive controls must be documented in the new “Items Noted For Improvement” (INFI) document for any PCI DSS v4.0 assessment.

The assessor provides the INFI document to the assessed company at the end of the assessment and both parties sign it. The INFI document proves that the assessed company has success­fully managed the devia­tions. The document can be used inter­nally within the assessed company — e.g. in compliance and risk depart­ments — and can also be shared with third parties if desired. There is no oblig­ation to present the INFI document anywhere, nor is it refer­enced in the Attes­tation of Compliance (A.O.C).

 Partic­u­larly for processes that have to be repeated regularly, it happens from time to time that one instance is delayed, e.g. within the imple­men­tation of 

  • security awareness trainings,
  • inspection of payment devices,
  • vulner­a­bility scans, or
  • instal­lation of patches.

It is best to consider in advance how you can design your processes in such a way that you adhere to the prescribed time periods and notice delays immedi­ately.

For further questions feel free to contact Mrs Jana Ehlers.

IT Security Act 2.0 approved by the Bundesrat (Upper House)

SRC GmbH: Pioneer in BSZ certi­fi­cation with expansion of the team of experts

In the following article you will learn more about how the SRC GmbH has been acting as a recog­nized test center for the BSZ since September 2021 and what important devel­op­ments and expertise it offers in this area.

Accel­erated Security Certi­fi­cation (BSZ): An Introduction

The BSZ is a procedure offered by the BSI in Germany to prove the security of IT products. It was intro­duced to give manufac­turers a faster way to demon­strate the security of their products with a BSI certificate. This assessment aims to ensure that the product meets the security require­ments of the BSI and offers end users an appro­priate level of protection. Compared to the conven­tional certi­fi­cation according to Common Criteria (CC), the BSZ offers the advantage of faster certi­fi­cation, easier to plan evalu­ation times, and a signif­i­cantly reduced documen­tation effort for the manufac­turer. SRC is a testing center for accel­erated security certi­fi­cation (BSZ) recog­nized by the Federal Office for Infor­mation Security (BSI) and was one of the first recog­nized certi­fi­cation bodies at all.

The road to security: BSZ versus CC

The procedure only allows a single run, i.e. the product to be evaluated may not be changed during the evalu­ation. This greatly speeds up the process overall, but there is always a risk that products will fail the first attempt and therefore not receive a certificate. In this case, however, a new certi­fi­cation procedure can be requested from the BSI at any time.

Under the direction of Peter Jung: The first steps of the SRC with BSZ

Under the project management of Peter Jung, who has been respon­sible for the BSZ at SRC from the start, SCR has since evaluated the Lancom 1900EF VPN router, which was also the first BSZ product ever, and then the secunet high-speed connector. As soon as this is evaluated, we will report on it in another article.

New expertise at SRC: Tim Hirschberg and Dr. Matthieu Felsinger

We are happy to announce that since May 2023 the SRC has been formed with Tim Hirschberg (BSZ evaluator) and Dr. Matthias Heuft (BSZ evaluator) and Dirk Feldhusen (BSZ evaluator for cryptog­raphy) — strengthen.

The BSZ certi­fi­cation in detail: concen­tration on promises of security

The BSZ certi­fi­cation focuses on verifying the safety perfor­mance promised by the manufac­turer. The actual certi­fi­cation is carried out after the product has been evaluated by a test center recog­nized by the BSI, such as the SRC. The resulting test report serves the BSI as a basis for awarding the certificate.

The path to the certificate: the verifi­cation process at SRC

The evalu­ation takes place within a fixed timeframe (about 2–3 months) that depends on the complexity of the product. The evalu­ation services include checking the promised security function­ality (conformity tests) and the instal­lation instruc­tions as well as penetration tests, in which the effec­tiveness of the technical security measures of the product is checked under realistic attack scenarios.

Cryptocur­rency ECB Digital EuroA Holistic Review: Cryptog­raphy and Beyond

The assessment of the imple­mented crypto­graphic proce­dures is also part of the compre­hensive testing process that an IT product has to go through in order to receive the BSZ certification.

A look into the future of safety certification

At SRC GmbH, we are proud of our role as a recog­nized testing body for accel­erated security certi­fi­cation (BSZ) and of contin­u­ously promoting security standards in the IT industry. With our experi­enced team and commitment to innovation, we will continue to help ensure the security of IT products.

If you would like to learn more about our BSZ certi­fi­cation services or have any questions, please do not hesitate to contact us. Together we can meet the safety require­ments of your products and pave the way for certi­fi­cation. We look forward to working with you and shaping the future of safety certification.

PCI DSS v4.0

PCI DSS v4.0 blog entry for September

Timeline for PCI DSS v4.0 migration – What are the next steps?

With March 31, 2024, the end of PCI DSS v3.2.1 is approaching. All merchants accepting payments with cards of the inter­na­tional payment brands Visa, Mastercard, American Express, Discover, JCB, or UnionPay, and all service providers supporting them, should be prepared for PCI DSS v4.0.

But what should be done in particular, and when?

Gap analysis

The first step should be a gap analysis. Anyone who has not yet checked which new require­ments come up to them with PCI DSS v4.0 should do so as soon as possible! The reasons are obvious:

  • Imple­menting new require­ments will require time and resources.
  • PCI DSS profes­sionals who can advise on imple­men­tation are already well booked.

During the gap analysis, the new require­ments must be read, under­stood, and aligned with the existing landscape of controls. To under­stand the require­ments, it is extremely helpful to read not only the requirement itself, but also the extensive guidance that the PCI SSC has provided alongside each requirement within the standard:

  • The “Guidance” column (to the right of the requirement),
  • the objective being pursued by the requirement (below the requirement),
  • and, if available, the applic­a­bility note (below the requirement).

The intro­ductory chapters of PCI DSS v4.0 and the glossary in Appendix G can also support in under­standing termi­nology and applicability.

If you work with a PCI DSS expert at present, feel free to draw on their expertise and experience within this step already.


When all open items have been identified, timeframes and respon­si­bil­ities should be assigned. When assigning timeframes, the following should be considered:

  1. How long will the imple­men­tation take?

The imple­men­tation of new technical solutions often takes a long time due to internal depen­dencies. Often this comes together with low human resources. Issues that are expected to take a long time to implement need to be addressed earlier than those where a quick completion is expected.

  1. Are targeted risk analyses required?

In v4.0, for many regular tasks the frequency of perfor­mance is no longer prede­fined, but is to be deter­mined by a targeted risk analysis. The imple­men­tation of such targeted risk analyses must be coordi­nated inter­nally and hence requires time.

  1. Are there periods that are partic­u­larly good or bad for implementation?
    g. for policy changes, it can make sense to consider document review cycles. For technical changes, it makes sense to consider any freeze periods or release periods that have already been planned.
  2. Is the PCI DSS v4.0 deadline for this requirement 2024 or 2025?

For many funda­men­tally new require­ments in PCI DSS v4.0, the applic­a­bility notes state that the requirement is considered best practice until 31 March 2025, after which it is mandatory.

Require­ments without this note must be imple­mented by 31 March 2024 and might therefore require a higher prioritisation


For some new require­ments, there are different ways to implement them. Examples are:

  • Requirement 3.4.2 calls for preventing copying/moving of PAN when accessing remotely (except for personnel with appro­priate business need). There can be several ways to implement this, too — e.g. via a setting in RDP when using the remote connection, or by preventing highlight­ing/­copy­ing/­mouse-right-clicking on PAN displays on according web pages.
  • Requirement 8.4.2 requires multi-factor authen­ti­cation (MFA) when accessing the Cardholder Data Environment (CDE).Depending on how the access towards the CDE takes place, it may make sense to enforce MFA at network level, at system level, or at appli­cation level. This decision must be well weighed with the various parties involved. Several parties may even have to work together on the solution.

Weigh up the impact of different solutions at an early stage!

Tracking and Assessing

Once you have priori­tised your tasks and decided on imple­men­tation paths: please do not sit back! The person or team respon­sible for maintaining PCI DSS compliance should stay in contact with the teams respon­sible for the implementation.

  • Are there any enquiries/comprehension issues?
  • Do any problems with the imple­men­tation arise?
  • Is the agreed target date at risk?

As soon as a new solution has been imple­mented, it should be checked whether it meets the corre­sponding PCI DSS requirement. External PCI DSS experts can also support with small interim pre-assess­ments in order to be on the safe side for the next official annual assessment.

Continuous Process

Once a requirement is met, there is no guarantee that it will remain so. Card data usage, technologies and attack vectors change. Already today, PCI DSS v3.2.1 comprises regular tasks for maintaining PCI DSS compliance. With PCI DSS v4.0, this is becoming even more of an ongoing process.

Therefore, get into the habit of putting your controls to the test repeatedly, and of adhering to the timeframes for recurring activ­ities (now precisely defined in chapter 7 of the PCI DSS). This will also make it easier for you to comply with new corre­sponding require­ments, such as e.g.

  • 2.4 / Review of user accounts and assigned access rights,
  • 3 Review of risk assess­ments and review of the appro­pri­ateness and security of crypto­graphic algorithms, hardware and software technologies used,
  • 5 Validate the PCI DSS appli­cation scope; and
  • 6.2 Review of the security awareness programme.

Above All: Start!

This is the most important step. If you haven’t started yet, today is the best day to do so. Assemble a team and schedule time.

Should you need any assis­tance do not hesitate to contact Jana Ehlers via email.

PCI DSS v4.0 approaches – we support your preparation

PCI DSS is a mature standard that defines require­ments for secure processing of card data of the inter­na­tional payment brands.
Version 3 of PCI DSS, which has been valid since 2014 — with various updates -, will finally expire at the end of March 2024 and will be replaced by the new version 4.0.

We take the final steps to PCI DSS v4.0 migration with you. Please make use of our offers:

1. Monthly blog articles highlighting one PCI DSS v4.0 topic at a time

2. Free webinars summa­rizing the changes from PCI DSS v3.2.1 to v4.0 again

  • Webinar on the full PCI DSS scope (January 2023)
  • Webinar for card-present merchants with SAQ B‑IP or P2PE scope (January 2023)
  • Webinar for e‑commerce merchants with SAQ A scope (January 2023)

You find an overview about the current webinars here.

3. PCI DSS v4.0 workshops tailored to your needs, in which we specif­i­cally present and discuss the require­ments that are relevant to you.

4. A gap-analysis of your environ­ments and processes. You will receive a list of all open items for PCI DSS v4.0 compliance in your company.

5. Consul­tancy packages of your choice. You can call up quotas at any time if you have specific queries — by telephone, e‑mail, web conference, or in meetings on site.

Please feel free to contact Mrs Jana Ehler via e‑mail for further inquiries.


Intensive seminar | Basic knowledge of IT basics and security measures for non-IT specialists on 15 November 2021

Intensive seminar (online)
Basic knowledge of IT basics and security measures for non-IT specialists

Bank IT in particular is required to protect sensitive infor­mation and data with a high level of security and at the same time make it available to autho­rised persons. To achieve this, infor­mation security officers, data protection officers, IT officers and other bank employees must coordinate closely. Despite different profes­sional backgrounds, a common “language” must be found. To do this, it is advan­ta­geous to be able to visualise the conceptual world of IT in the context of its processes and inter­re­la­tion­ships. This is the only way to succeed in an inter­dis­ci­plinary exchange with IT experts about IT security measures and their effects in the company and its diverse internal and external commu­ni­cation structures.

The intensive seminar “Basic knowledge of IT basics and security measures for non-IT experts” provides the necessary knowledge about infor­mation technology and security measures. The target group is non-IT specialists in credit institutions.

The speaker Florian Schumann is IT manager at SRC Security Research & Consulting GmbH. In this position, he is respon­sible for the continuous devel­opment of IT. He is also a consultant for infor­mation security and a qualified auditor according to § 8 (a) BSIG for critical infrastructures.

Module 1: IT terms and basics

  • Networks
  • Commu­ni­cation media and protocols
  • Basic IT security measures in networks
  • Basic IT security measures in data centres
  • Backup & Restore
  • Virtu­al­i­sation
  • Concepts of user administration

Module 2: Encryption

  • Symmet­rical and asymmet­rical procedures
  • key management
  • Signature
  • Authen­ti­cation (e.g. multi-factor authen­ti­cation according to PSD2) and integrity assurance

In addition, partic­i­pants will receive an overview of new technologies and trends, e.g. big data, cloud, artificial intel­li­gence, special features of mobile working / home office. The intensive seminar offers suffi­cient space to reflect on the upcoming challenges for security.

Intensive seminar (online)

Basic knowledge of IT basics and security measures for non-IT specialists
on Monday, 15 November 2021, 10:00 a.m. to 5:00 p.m.



Certificate Course “Infor­mation Security Officer for Credit Insti­tu­tions” — November 16 to 19, 2021

The German Banking Act (KWG) and MaRisk require banks to ensure the integrity, avail­ability, authen­ticity and confi­den­tiality of data in their IT systems and processes. But secure and efficient IT is also absolutely essential for the economic success of a credit institution.

The new “Banking Super­visory Require­ments for IT” (BAIT) formulate concrete expec­ta­tions. Among other things, the Federal Financial Super­visory Authority calls for the newly estab­lished function of “infor­mation security officer” in its directive. This officer controls the infor­mation security process and reports directly to the management.

In cooper­ation with the publishing house Bank-Verlag, SRC has success­fully completed multiple certificate courses to become an “Infor­mation Security Officer (ISB) for credit insti­tu­tions” since 2016. After the great response and the continuing demand, we are pleased that the Bank-Verlag has made another date for this four-day certificate course possible.

From 16th to 19th November 2021, you will again have the oppor­tunity to train as an “Infor­mation Security Officer (ISB) for Credit Insti­tu­tions” on the premises of Bank-Verlag GmbH in Cologne.

Attention! Online-course

Taking into account the current Covid-19 situation, we offer both the certificate course Infor­mation Security Officer (ISB) for credit insti­tu­tions and the optional basic IT seminar as an online course.

In a team with Heinrich Lottmann (TARGOBANK AG & Co. KGaA) and Alexandros Manakos (HSBC Germany), the SRC experts Dagmar Schoppe, Florian Schumann and Dr. Deniz Ulucay will give a lecture and provide you with compre­hensive infor­mation on the norms and standards according to ISO and IT-Grund­schutz, as well as on all legal/regulatory require­ments relevant for you as an ISB. In addition, the topics of IT risks and emergency precau­tions as well as business conti­nuity management will be addressed.

After passing the final exami­nation, you will receive the certificate “Infor­mation Security Officer for Credit Institutions”.

Optionally, you have the oppor­tunity to acquire the basic IT knowledge required for the course in a one-day intensive seminar on 15 November 2021 in Cologne prior to the event. This seminar deals with the basics, terms, encryption and IT security techniques in infor­mation technology.

Web-Site to the course


Appli­cation areas of Digital Identities: Digitally repre­senting — and protecting — physical identities

Appli­cation areas of digital identities:

Digitally repre­senting — and protecting — physical identities

With the current devel­opment of the European Regulation on Electronic Identi­fi­cation and Trust Services (eIDAS), a recog­nised and secure digital identity can come about throughout Europe. Digital identities have been common­place for a long time — from email accounts to social media to digital official trans­ac­tions: The use of digital services requires proof of identity. The necessary identi­fi­cation and authen­ti­cation is linked to different levels of protection, depending on the service used. Companies that want to offer services for which digital identities are necessary — for employees, partners and customers — must know the requirements.

A digital identity is the digital repre­sen­tation of a physical identity. The latter can be a person, but also an insti­tution, a machine or a server. In the health sector, practices, hospitals or pharmacies, for example, can receive a digital identity. In this context, it repre­sents a collection of attributes in electronic form that charac­terise a natural or legal person — this can be name, address and date of birth, but also user name or email address. A digital ID must be unique, otherwise it cannot be assigned; the process of initial identi­fi­cation is trans­ferred to the digital — for initial identi­fi­cation it requires regis­tration; recog­nition is achieved through authen­ti­cation. From a social perspective, there are three forms of identities: real, self-constructed and anonymous, with the latter playing a sometimes contro­versial role on social media, for example.

Possible uses of digital identities

Digital identities are necessary as a basis or digital repre­sen­tation for digital services and processes. They are used wherever digital services are offered and are person­alised, which requires the collection, storage and processing of data. Digital services have various forms — from social media user accounts, to online accounts in e‑commerce, to online banking or digital official proce­dures via eGovernment offerings. As with the identity card, the scope of appli­cation of a digital identity can go beyond mere identi­fi­cation and, for example, an age check can be possible.

Increasing digital­i­sation is opening up further possible uses of a digital identity: The European eIDAS (Regulation on Electronic Identi­fi­cation and Trust Services) creates uniform framework condi­tions for the use of electronic means of identi­fi­cation and trust services across borders here. In 2020, the revision of the eIDAS Directive was launched, and it is currently not yet complete. The goal is to offer a secure EU identity wallet throughout Europe. The eID is thus the virtual equiv­alent of an identity card. It is supposed to enable identi­fi­cation and authen­ti­cation, verifi­cation of validity by third parties as well as secure storage and repre­sen­tation of identities. In addition, it should make it possible to generate qualified electronic signa­tures. This digital counterpart to the signature allows legally valid contracts to be concluded on a digital level.

The eIDAS also stipu­lates that EU member states must make the digital identity available to citizens; the envisaged accep­tance oblig­ation may also contribute to the elimi­nation of other digital identities. Shopping abroad or picking up a rental car could thus be simplified, as the digital identity makes processes more efficient. This is because digital services are associated with a reduction in costs compared to analogue processes; the user benefits greatly from simpler and more conve­nient handling, for example, when admin­is­trative proce­dures can be completed from home.

Unlike digital identities via Google or Facebook, the author­ities can ensure that data protection is complied with in accor­dance with the Data Protection Regulation (DSGVO). In the health sector, digital identities on the smart­phone are to replace the electronic health card in the future — but this cannot yet be realised.

Security and protection of the user

One possible attack scenario that partic­u­larly affects digital identities is theft in the form of imper­son­ation or identity theft. The potential for damage ranges from hate comments on social media to access to and misuse of personal data, such as banking trans­ac­tions or confi­dential health data. While the analogue identity card limits misuse by thieves because of the photo on it, the case is different online. The digital identity must therefore be specially protected. Protective measures can be, for example, secure passwords or a two-factor authen­ti­cation, as it already takes place in online banking, for example, with a password on the one hand and additional TAN gener­ation on an external device on the other. The hardware token in smart cards repre­sents the highest level of security as a certified version.

Standardised trust levels

The level of security depends on the purpose of the digital identity and is regulated in the Imple­menting Regulation (EU) 2015/1502. For example, in online banking or in the health sector, there are partic­u­larly sensitive, personal data that require a high level of protection. The regulation defines three standardised trust levels: low, substantial and high. A low level of protection corre­sponds to a one-factor authen­ti­cation, as is common in social networks or forums. Substantial protection is provided by the afore­men­tioned two-factor authen­ti­cation. However, a high level of protection, for example when health data is involved, must be even more strongly secured, for example with a passport including a photo and biometric features. For example, identi­fi­cation can take place via video-identi­fi­cation or post-identi­fi­cation procedures.

However, the higher the security level, the more compli­cated its technical imple­men­tation. High-priced smart­phones, for example, come with certified security compo­nents — while lower-priced devices are equipped with inferior biometric sensors that can be easily manip­u­lated or bypassed. They therefore do not have protected memory areas. Smart cards in health cards, on the other hand, can use and store crypto­graphic key material with their chip processors. In this way, the infra­struc­tures behind them ensure authenticity.

The future potential of digital identities

Digiti­sation is on the rise, all its services require a digital identity and these are already widespread: On average, every citizen has 90 digital identities. The digital and analogue worlds can merge, for example when access controls in companies are digitalised and require proof of a digital identity, or when the health card is read in as an ID in doctors’ surgeries. Here, media disrup­tions are perceived as an obstacle, for example when paper documents are to be submitted as scans to health insurance companies. Digital identities and the assignment they allow make the digiti­sation of such processes possible in the first place. In the area of eHealth, doctors can digitally sign and send invoices and prescrip­tions, for example.

Companies, in turn, can use digital identities widely for customers and employees, end customers or partners. This means, for example, that holiday appli­ca­tions can be made via a portal. Not to be neglected are also conceivable appli­cation possi­bil­ities for customer loyalty: After all, digital services that customers use can be used to gain infor­mation about their behaviour, which can be used to better tailor and optimise one’s own offer. However, companies must be aware of the different levels of security. User-friend­liness is important, but so is digital protection against identity and data theft. If this is not guaranteed, serious conse­quences can be the result. A consulting firm like SRC GmbH can help here to shed light on solutions — both paid and open source — to check certi­fi­ca­tions and to ensure conformity and thus legal certainty.


Nothing works on the internet without digital identities — digital services require initial identi­fi­cation of the user and authen­ti­cation for further use, for example, via passwords with additional TAN gener­ation within the framework of multi­factor proce­dures. The security require­ments depend on the type of service and the data used, which is ensured via three levels. Companies that want to use digital services must therefore know the require­ments in order to use the appli­cation potential for customers, partners or suppliers.


Author: Nico Martens, Consultant SRC Security Research & Consulting GmbH

Further infor­mation:

Press contact:

Patrick Schulze


Lornsen­strasse 128–130

22869 Schenefeld

Phone +49 (0) 40 840 55 92–18