Study Guide
Security Teams and Competencies
What security professionals need to be able to do, and how the work is shared between a Security Operations Centre, an incident response team and DevSecOps, followed through one change: adopting a cloud platform.
Lesson 5.16 Governance, Risk & Compliance
Security Roles and Responsibilities asked who is responsible for security. This lesson works out what security work actually consists of, how it is shared out between teams, and how one change passes through every role and team.
Stage: Think
Watch, respond, build
Think it through
A hospital has people who watch patients’ monitors, a crash team that rushes in when something goes wrong, and builders who design new wards to be safe from the start. What might the security equivalents of those three groups do?
- Hint 1: What does each hospital group do before, during and after a problem?
Show what happens
One group watches systems for signs of trouble, one takes charge when an incident happens, and one builds security into new systems from the beginning. The lesson names three security teams that divide the work this way.
Think it through
Show the answer
Answer: A. Rarely.
Rarely. Security work calls on several different competencies, so it is shared out between people and teams.
Stage: Predict
What security professionals need to be able to do
A competency is something a person is able to do well: knowledge and practical skill together. Information security work calls on seven competencies:
- Risk assessments and testing
- Access control and user privileges
- Incident response and reporting
- Security training and education programmes
- Specifying, sourcing, installing and configuring secure devices and software
- Auditing logs and events
- Business continuity and disaster recovery
Think it through
Look at the seven competencies. Could you arrange them as a loop, in which each feeds the next? Try.
- Hint 1: Which one would you start with, and which would lead back to it?
Show what happens
One way: assess risk, control access, secure systems, monitor activity, respond to incidents, recover operations, then improve people and processes, and round again. The diagram uses that order.
It is easier to remember them as connected capability areas than as a list. One way to arrange them is as a loop, in which each area feeds the next.
The seven competencies arranged as a loop. The order is a way of remembering them; in practice they all run at once.
- Assess risk
Risk assessments and testing: find out what could go wrong, and check whether the defences work.
- Control access
Access control and user privileges: decide who can reach what, and keep it to what each person needs.
- Secure systems
Specifying, sourcing, installing and configuring secure devices and software.
- Monitor activity
Auditing logs and events: notice what is actually happening.
- Respond to incidents
Incident response and reporting: act when something goes wrong, and tell the people who need to know.
- Recover operations
Business continuity and disaster recovery: keep essential work going, and restore what was lost.
- Improve people and processes
Security training and education programmes: help everyone do the right thing next time.
↺ Return to step 1, Assess risk, and repeat.
The seven areas in plain words
Comparison table: scroll horizontally on narrow screens.
| Competency | What it means | An everyday example |
|---|---|---|
| Risk assessments and testing | Working out what could go wrong and how much it would matter, and checking whether defences really work. | Assessing the risks of a new supplier; arranging an authorised test of a website. |
| Access control and user privileges | Deciding who may use which systems and information, and with which permissions. | Removing a leaver’s accounts; reviewing who has administrator rights. |
| Incident response and reporting | Dealing with a security incident, and reporting it to the right people. | Isolating an infected laptop; writing up what happened. |
| Security training and education programmes | Helping staff understand the risks and what is expected of them. | Running a session on spotting phishing emails. |
| Specifying, sourcing, installing and configuring secure devices and software | Choosing suitable equipment and software, obtaining it from a trustworthy source and setting it up securely. | Setting up new laptops with encryption switched on and unneeded features switched off. |
| Auditing logs and events | Reviewing records of what happened on systems, to find problems and to show who did what. | Checking sign-in logs for attempts from unexpected places. |
| Business continuity and disaster recovery | Keeping essential work going during a disruption, and restoring systems and data after a serious failure. | Testing that last night’s backup can actually be restored. |
Check your understanding
Show the answer
Answer: B. Business continuity and disaster recovery
Business continuity and disaster recovery: knowing that data can really be restored after a failure.
Each area is taught elsewhere in the Study Guide. Risk and Identity and Access Management are good places to start, and the loop as a whole has the same shape as the Functions in The NIST Cybersecurity Framework.
Stage: Predict
Security teams and what each focuses on
No one person does all seven. Larger organisations divide the work between teams. Three are covered here, sometimes called security business units.
| Team | Stands for | Focus | Memory aid |
|---|---|---|---|
| SOC | Security Operations Centre | Continuous monitoring, detection, analysis, investigation and escalation. | The SOC watches. |
| CIRT or CERT | Computer Incident Response Team, or Computer Emergency Response Team | Responding to security incidents, including investigation, containment and coordinating recovery. | The CIRT responds. |
| DevSecOps | Development, Security and Operations | Building security into software and system development and operations from the beginning, not adding it at the end. | DevSecOps builds securely. |
Check your understanding
Show the answer
Answer: C. CIRT or CERT
The CIRT or CERT, the incident response team.
Security Operations Centre
A Security Operations Centre is a team that watches the organisation’s systems, often around the clock. Its analysts review alerts and logs, decide which ones are real problems, investigate them and escalate confirmed incidents, which means passing them to the people who will deal with them.
Think it through
Show the answer
Answer: A. Yes: watching is not preventing.
Yes. A SOC watches, detects and escalates; it does not make a breach impossible.
A small organisation rarely builds its own. It may buy monitoring as a service from a provider instead. Either way, a SOC does not make an organisation safe by existing: as Compliance vs security explains, an organisation can run one continuously and still suffer a breach.
Incident response team
When an incident is confirmed, someone has to take charge. An incident response team finds out what happened, stops it spreading, coordinates the return to normal working and keeps the right people informed. Containment is the word for stopping an incident spreading, for example by disconnecting an infected computer from the network.
Check your understanding
Show the answer
Answer: C. Containment
Containment: stopping the incident spreading.
The team goes by several names that mean the same thing: CIRT (Computer Incident Response Team), CERT (Computer Emergency Response Team) and CSIRT (Computer Security Incident Response Team). It may be permanent, or it may be assembled when needed from IT, security, legal, communications and management.
DevSecOps
DevOps is a way of working in which the people who develop software and the people who operate it work as one team, so that changes reach users quickly and reliably. DevSecOps adds security to that from the start: code and configuration are checked as they are written, tests run automatically, and secure settings are the default.
Think it through
Why might it be cheaper to build security into software from the start than to review it at the end?
- Hint 1: How hard is it to change something that is already finished?
Show what happens
Problems found at the end are expensive to fix and tempting to ignore; found while the code is being written, they are small and quick to correct.
The alternative is to build the whole system and ask for a security review at the end. Problems found then are expensive to fix and tempting to ignore. DevSecOps is as much a way of working as a team, although many organisations do have people or a team with that name.
Stage: Explain
A role is not a team
The SOC, the incident response team and DevSecOps are teams or functions: groups that do a kind of work. An ISSO (Information Systems Security Officer) is an individual role: one person responsible for the security of particular systems. The two are easy to mix up when a scenario question lists an ISSO alongside these teams.
Check your understanding
Show the answer
Answer: C. No, a role.
No. The ISSO is an individual role, responsible for the security of particular systems.
Two questions keep them apart:
- “Which person is responsible for this system’s security?” points to a role, such as the ISSO.
- “Which group does this kind of work?” points to a team, such as the SOC.
All six memory aids together. The first three are the roles from Security Roles and Responsibilities: the Chief Information Officer (CIO), the Chief Information Security Officer (CISO) or Chief Security Officer (CSO), and the ISSO.
| Role or team | Kind | Memory aid |
|---|---|---|
| CIO | Individual role | Leads IT. |
| CISO or CSO | Individual role | Leads security. |
| ISSO | Individual role | Oversees system security. |
| SOC | Team | Watches. |
| CIRT or CERT | Team | Responds. |
| DevSecOps | Team or way of working | Builds securely. |
Stage: Predict
One change, six contributions
A single change shows how the roles and teams fit together. The organisation below is fictional.
Think it through
An organisation moves its customer service system to a cloud platform. Using the six roles and teams, suggest what each might contribute.
- Hint 1: Start with the strategy and end with an incident.
An original diagram with a fictional scenario. Each entry is labelled as an individual role or as a team, with its memory aid and its contribution to this one change.
The changeA fictional organisation decides to move its customer service system to a cloud platform.
Individual role
CIO
Leads IT
Decides how the platform fits the organisation’s IT strategy and how it will be run.
Individual role
CISO or CSO
Leads security
Considers the security strategy, the risks and the controls the platform must have.
Team or function
DevSecOps
Builds securely
Builds security into how the system is developed and deployed, where the organisation develops its own software.
Individual role
ISSO
Oversees system security
Checks this system’s controls, documentation and known weaknesses, and that fixes are made.
Team or function
SOC
Watches
Monitors the security events the platform produces, and escalates anything suspicious.
Team or function
CIRT or CERT
Responds
Takes charge if a security incident occurs: investigates, contains it and coordinates recovery.
The numbers show the order in which each contribution usually begins. In practice they overlap, and most continue for as long as the platform is in use.
Stage: Predict
How the teams hand over
Think it through
Show the answer
Answer: C. The response never starts.
Nobody takes charge of the response: the hand-over to the incident response team never happens.
The teams depend on passing work to each other.
- SOC to incident response. When the SOC confirms that an alert is a real incident, it escalates to the incident response team.
- Incident response to the builders. What the team learns becomes fixes for DevSecOps to build in, and updated documentation for the ISSO.
- Upwards. The ISSO reports the system’s risks to the CISO, and the CISO and CIO agree priorities.
- The SOC escalates. At 2 a.m. the SOC sees sign-ins to a finance account from an unexpected country, confirms that they are not the account’s owner and escalates to the incident response team.
- The response team takes charge. It disables the account, finds that a phishing email captured the password, checks what the account opened and coordinates the return to normal working.
- The lessons reach the builders. DevSecOps adds a stronger sign-in check to the finance application, and the ISSO updates the system’s documentation and reports the remaining risk to the CISO.
The result: each hand-over moved the work on. A missed one, an alert nobody escalated or a lesson nobody passed on, would have left the problem in place.
Hand-overs are where things go wrong. An alert that nobody escalates, or a lesson that never reaches the people building the next system, is the kind of gap that departmental silos create.
In a small organisation, one or two people may do all of this, and monitoring or incident response may be bought in. The titles disappear. The work does not: someone still has to watch, someone still has to respond and someone still has to build things securely.
If you work on a service desk, you are often the first step in this chain. A user reporting something odd is an event that may need escalating, and knowing who your organisation’s security contact is, and how to reach them out of hours, is the practical form of everything in this lesson.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: A. Report it to security.
Escalate it to the organisation’s security contact: an odd report is an event that may need investigating.
Apply it
Show the answer
Answer: C. No, it remains.
No. The titles disappear, but someone still has to watch, respond and build securely, or buy those services in.
Apply it
Show the answer
Answer: C. Escalate to the response team.
The SOC escalates, and the incident response team takes charge of containment and recovery.
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: Auditing logs and events
Auditing logs and events, one of the information security competencies, means reviewing records of what happened on systems, and checking sign-in records for unexpected attempts is exactly that. Business continuity and disaster recovery is about keeping work going and restoring systems, training and education is about helping staff understand the risks, and specifying, sourcing, installing and configuring is about choosing equipment and software and setting it up securely.
Revision sources: Session 7: Security+ Session 1 — Security Concepts, Controls and Roles (Classroom session record) · Security Teams and Competencies (Supplementary Study Guide explanation)
Show answer
Answer: Risk assessments and testing; Access control and user privileges; Incident response and reporting
The seven competencies are risk assessments and testing; access control and user privileges; incident response and reporting; security training and education programmes; specifying, sourcing, installing and configuring secure devices and software; auditing logs and events; and business continuity and disaster recovery. Risk assessments and testing, access control and user privileges, and incident response and reporting are all on that list. Designing cryptographic algorithms and developing business applications are not: they are specialist or wider technology work, not among the seven.
Revision sources: Session 7: Security+ Session 1 — Security Concepts, Controls and Roles (Classroom session record)
Show answer
Answer: Auditing logs and events; access control and user privileges
Auditing logs and events, and access control and user privileges, are two of the seven information security competencies. Reviewing the sign-in logs is auditing, and removing accounts that should no longer exist is access control, so the finding comes from one area and the fix from another. The competencies are connected capability areas for this reason: the work of one feeds the next. Nothing suggests an incident or a disruption, so incident response and business continuity are not what is being used here, and no training or new equipment is involved.
Revision sources: Session 7: Security+ Session 1 — Security Concepts, Controls and Roles (Classroom session record) · Security Teams and Competencies (Supplementary Study Guide explanation)
Show answer
Answer: SOC: watches. CIRT: responds to incidents. DevSecOps: builds securely.
The SOC, DevSecOps and the CIRT are security business units, each with its own focus. The Security Operations Centre focuses on continuous monitoring, detection, analysis, investigation and escalation. The Computer Incident Response Team focuses on responding to incidents, including investigation, containment and coordinating recovery. DevSecOps builds security into development and operations from the beginning, instead of adding it at the end.
Revision sources: Session 7: Security+ Session 1 — Security Concepts, Controls and Roles (Classroom session record) · Security Teams and Competencies (Supplementary Study Guide explanation)
Show answer
Answer: The SOC escalates it to the incident response team, which leads the response.
The teams hand work to each other: the SOC escalates a confirmed incident to the incident response team, whose focus is investigating the incident, containing it and coordinating recovery. The SOC focuses on monitoring, detection, analysis, investigation and escalation, so once an incident is confirmed its part is to pass it on, not to wait. DevSecOps builds security into development and operations; it may later build in the fixes, but it does not lead the response. The Information Systems Security Officer is an individual role that looks after a system’s controls and documentation, not the team that responds to incidents.
Revision sources: Security Teams and Competencies (Supplementary Study Guide explanation)
Show answer
Answer: Information Systems Security Officer (ISSO)
The Security Operations Centre (SOC), DevSecOps and the Computer Incident Response Team (CIRT) are security business units, while the Information Systems Security Officer (ISSO) is a role. The ISSO is an individual role responsible for the security of particular systems, including their documentation and controls, which matches the responsibility described. The SOC, DevSecOps and the incident response team are teams or functions with a different focus: the SOC monitors, DevSecOps builds security in, and the incident response team responds to incidents. A useful check is to ask whether a question is about which person is responsible for a system, or about which group does a kind of work.
Revision sources: Session 7: Security+ Session 1 — Security Concepts, Controls and Roles (Classroom session record) · Security Teams and Competencies (Supplementary Study Guide explanation)
Show answer
Answer: Monitoring the security events that the platform produces: the Security Operations Centre (SOC)
Six contributors are involved in a move like this. The Chief Information Officer (CIO) decides how the platform fits IT strategy and operations. The Chief Information Security Officer (CISO) or Chief Security Officer (CSO) considers security strategy, risk and the controls required. DevSecOps builds security into development and deployment. The Information Systems Security Officer (ISSO) checks the system’s controls, documentation, vulnerabilities and remediation. The Security Operations Centre (SOC) monitors the resulting security events, and the incident response team responds if a security incident occurs. Monitoring the platform’s security events is therefore the SOC’s contribution.
Revision sources: Security Teams and Competencies (Supplementary Study Guide explanation)
Study and revision
Practise through the Governance & Policy revision topic. Questions cover matching a task to a competency area, which areas were listed, matching each team to its focus, what happens when an alert becomes an incident, the ISSO as a role, and the cloud-platform scenario; two flashcards recall the seven areas and the memory aids for the teams. Items that use this lesson’s supplementary explanation say so. They are learning-only, and the lesson does not establish exam alignment or practical experience.
Stage: Consolidate
What to remember
- Security work calls on seven connected competencies, from assessing risk to improving people and processes.
- The SOC watches; the CIRT or CERT responds; DevSecOps builds securely.
- Roles are people; teams are groups: the ISSO is a role, the SOC a team.
- One change involves every role and team, each contributing at its own point.
- Hand-overs are where things go wrong; in small organisations the titles vanish, but the work remains.
Key terms
- SOC (Security Operations Centre)
A team that continuously monitors an organisation’s systems, detecting, analysing and investigating possible security incidents and escalating confirmed ones.
- CIRT (Computer Incident Response Team)
A team that responds to security incidents: investigating what happened, containing the incident and coordinating recovery.
- DevSecOps (Development, Security and Operations)
A way of working that builds security into software and system development and operations from the beginning, instead of adding it at the end.
Common misunderstandings
The SOC’s focus is watching: monitoring, detecting, investigating and escalating. Leading the response is the incident response team’s focus, even where the same people do both.
They are different names for the same kind of team. CSIRT is a third.
It is a way of working that builds security in from the beginning. Tools support it.
It is an individual role, responsible for the security of particular systems.
They are connected capability areas. Most security roles need several of them.
Further reading
Lesson sources and acknowledgements
Sources and scope
- Covered in Session 7 (see the Session 7 Learning Log): the seven competencies, as listed; the SOC, DevSecOps and the CIRT as security business units; and the ISSO discussed as a role in exam-style scenario questions.
- Recorded in Session 4: an organisation can operate a Security Operations Centre around the clock and still suffer a breach.
- Supplementary explanation: the definition of a competency, the loop and its ordering, the plain-word descriptions and examples of each area, the wording of each team’s focus, the descriptions of each team, CSIRT as a further name, the memory aids, the role-versus-team questions, the cloud-platform scenario and its diagram, the hand-overs, the practical note and the misunderstandings. These were developed afterwards and are my explanations, not the tutor’s words. The diagrams are original.
- Fictional example: the organisation adopting a cloud platform is invented.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the hospital opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. I have not worked in a SOC, an incident response team or a DevSecOps team.
The senior executive who typically leads an organisation’s information-technology strategy and operations.
A team that responds to security incidents: investigating what happened, containing the incident and coordinating recovery.
The senior executive who typically leads information and cybersecurity strategy, governance, risk and protection.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
A senior executive responsible for security across an organisation, whose remit may include physical and corporate security as well as information security.
A way of working that builds security into software and system development and operations from the beginning, instead of adding it at the end.
Transforming data with a cipher and a key so that it cannot be read without the right key. Decryption reverses it.
Protecting information by bringing together policies, processes and technical controls throughout the information’s lifecycle.
The person responsible for the security of particular information systems: that their controls are in place and that their documentation, risks and remediation are managed.
A deceptive message designed to trick the recipient into an action, such as revealing sign-in details or opening a malicious link.
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
An event that threatens or compromises the confidentiality, integrity or availability of information or systems.
A team that continuously monitors an organisation’s systems, detecting, analysing and investigating possible security incidents and escalating confirmed ones.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.