An Information Security Management System (ISMS) does not operate by intention alone. An organization can define a clear scope, establish a policy, assign roles, assess risks, and create objectives, but none of those things will function properly unless the ISMS is supported. This is where Clause 7 of the standard becomes relevant.
Clause 7 is called “Support” because it deals with the conditions that allow the ISMS to work in practice. It asks whether the organization has the resources it needs, whether the relevant people are competent, whether people are aware of their responsibilities, whether communication is planned, and whether documented information is properly managed. In this first part, we will focus on the first three areas: resources, competence, and awareness.
These requirements may look simple at first glance since the standard uses only a few sentences for each one. But in practice, Clause 7 is often where the difference between a paper-based ISMS and a working ISMS becomes visible. If there are no resources, nothing gets implemented. If people are not competent, controls are misunderstood or poorly operated. If people are not aware, the ISMS remains the concern of a few specialists rather than becoming part of how the organization works.
ISO 27001 requires the organization to determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the ISMS. It also requires the organization to determine necessary competence, ensure competence through education, training, or experience, take action where needed, evaluate the effectiveness of those actions, and retain documented evidence of competence. It further requires persons working under the organization’s control to be aware of the information security policy, their contribution to the ISMS, and the implications of not conforming with ISMS requirements.
1. Why Clause 7 matters
Clause 4 defined the organization’s context, interested parties, scope, and the need to establish the ISMS. Clause 5 placed responsibility on leadership. Clause 6 required planning, including risk-based actions, information security objectives, and planned changes.
Clause 7 now asks a practical question: what support is needed to make all of that real? This matters because an ISMS is not only a set of documents. ISO 27000 describes an ISMS as consisting of policies, procedures, guidelines, associated resources, and activities that are collectively managed by the organization in order to protect its information assets. It also describes an ISMS as a systematic approach for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving information security.
That means support is not secondary. It is part of the management system itself. A risk assessment process needs people who know how to perform it. A risk treatment plan needs budget, tools, authority, and time. A backup control needs infrastructure, storage, procedures, monitoring, and competent personnel. An incident response process needs trained people, defined responsibilities, and awareness among users so that events are reported. A policy needs people who understand it and know what it means for their work. Without support, the ISMS may exist formally, but it will not operate effectively.
2. Clause 7.1 Resources
Clause 7.1 is short, but it is not small. The organization must determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the ISMS. This requirement connects directly to leadership. In Clause 5, top management is required to ensure that the resources needed for the ISMS are available. Clause 7.1 then turns that leadership responsibility into a support requirement. It is not enough for management to say information security matters. The organization must provide what is necessary for the ISMS to function.
Resources can include many things. They can include people. For example, the organization may need an Information Security Officer, risk owners, asset owners, internal auditors, system administrators, incident handlers, project managers, and process owners who have time assigned to ISMS related activities.
They can include financial resources. For example, the organization may need budget for training, external advice, vulnerability scanning, security tools, awareness materials, certification audits, penetration testing, or secure document management.
They can include technical resources. For example, identity management systems, logging platforms, backup infrastructure, endpoint protection, ticketing systems, document repositories, monitoring tools, and secure communication channels may all support ISMS operation.
They can include physical and organizational resources. For example, meeting time, management review sessions, audit time, access to records, reporting structures, and defined decision-making channels are also resources.
The important point is that the organization should not treat resources as an abstract promise. It should be able to show that it has considered what is needed and that appropriate resources have actually been made available.
A practical example:
Imagine an organization has defined an information security objective to improve access control reviews. The objective says that user access rights for critical systems should be reviewed quarterly. On paper, this sounds reasonable. But who will export the access lists? Who will review them? Who will decide whether access is still required? Who will remove unnecessary access? Who will track completion? Who will follow up when managers do not respond?
What system will store the evidence? How much time will this take every quarter? If none of these questions are answered, the objective is not properly supported. Clause 7.1 pushes the organization to think about the resources needed to turn the objective into reality.
What an auditor may look for:
An auditor will usually not expect a single document called “Resource Plan for Clause 7.1.” That may exist, but it is not always necessary. The auditor will more likely look for evidence that the ISMS has been resourced in a realistic and effective way. This may include an ISMS project plan, budget approvals, job descriptions, role assignments, training plans, tool ownership, meeting minutes, management review records, risk treatment plans, or evidence that required activities are actually being performed. The key audit question is simple: has the organization provided what is needed for the ISMS to work?
If the ISMS depends on one overworked person, no allocated time, no management attention, no training budget, and no functioning evidence system, the organization may struggle to demonstrate that resources are adequate.
3. Clause 7.2, Competence
Clause 7.2 moves from resources in general to people in particular. The organization must determine the necessary competence of persons doing work under its control that affects information security performance. It must ensure that these persons are competent on the basis of appropriate education, training, or experience. Where needed, it must take action to acquire the necessary competence, evaluate the effectiveness of those actions, and retain appropriate documented information as evidence of competence. This requirement is important because many ISMS activities depend on judgement. The standard does not simply ask whether a person has attended a training course. It asks whether the organization has determined what competence is needed and whether the relevant persons are actually competent. Competence is not the same as awareness! Awareness means a person knows something relevant to the ISMS.
Competence means a person is able to apply knowledge and skills to achieve intended results. This distinction matters. A normal employee may need awareness of phishing risks, acceptable use rules, incident reporting, and the information security policy. But a person performing risk assessments needs competence in risk identification, risk analysis, risk evaluation, and risk treatment. An internal auditor needs competence in auditing and in the ISMS requirements being audited. A system administrator managing privileged access needs competence in identity management, access control, logging, and secure administration practices.
ISO/IEC 27003 treats awareness and competence provision as one of the management system processes that support an ISMS, along with planning, implementation, operation, performance assessment, management review, improvement, and documented information.
Determining necessary competence:
The first step is to determine what competence is necessary. This should be based on the organization’s ISMS scope, risks, controls, processes, technologies, and roles. For example, the organization may need competence in Information security risk assessment, Risk treatment planning, Supplier security assessment, Incident management, Access control administration, Secure configuration, Backup and recovery, Internal auditing, Legal and regulatory requirements, Business continuity, Document control, Security awareness delivery, Management review preparation. The organization should avoid making competence too vague. Saying “the Information Security Officer must understand ISO 27001” may be true, but it is not very useful. A better approach is to define competence in relation to actual responsibilities.
Example:
The person responsible for risk assessment should be able to apply the organization’s risk assessment methodology consistently, identify information security risks, assign risk owners, document results, and explain risk levels to management. The person responsible for access reviews should understand the access control policy, role requirements, approval rules, segregation of duties concerns, and evidence expectations. The person responsible for internal audits should understand audit principles, the ISMS audit programme, relevant ISO 27001 requirements, and how to identify conformity, nonconformity, and improvement potential.
How competence can be achieved:
Competence can come from education, training, or experience. This is important because the standard does not require every competent person to hold a formal certification. A person may be competent because they have formal education in information security. Another may be competent because they attended relevant training. Another may be competent because they have years of practical experience operating systems, managing incidents, or conducting audits. Another may become competent through mentoring, supervised work, reassignment, or external support.
The note under Clause 7.2 gives examples of actions that may be taken, such as training, mentoring, reassignment of current employees, or hiring or contracting competent persons. This is helpful for smaller organizations. They may not have all expertise internally. They may use external consultants, managed service providers, legal advisers, or specialist auditors. That can be acceptable, but the organization should still understand what competence is needed and how it is being covered.
Evaluating effectiveness:
A common weakness in ISMS implementations is that training is treated as evidence of competence by itself. Someone attends a course, receives a certificate, and the organization assumes the requirement is fulfilled. Training can support competence, but Clause 7.2 also requires the organization to evaluate the effectiveness of actions taken where applicable. This means the organization should ask whether the action actually helped.
Example:
After risk assessment training, are risk assessments more consistent?
After incident handling training, are incidents reported and escalated properly?
After internal auditor training, are audit reports clearer and more useful?
After access control training, are access reviews completed correctly?
After phishing awareness training, do users report suspicious messages more reliably?
This evaluation does not need to be complicated. It can be done through manager feedback, observation, test results, quality review, audit findings, incident metrics, or review of completed work.
Evidence of competence:
The standard requires appropriate documented information as evidence of competence.
This evidence might include: Training records, Certificates, Curriculum vitae, Role descriptions, Competence matrices, Onboarding records, Mentoring records, Performance reviews, Audit qualification records, Records of completed supervised activities, External service agreements showing specialist competence. The evidence should be appropriate to the role. A certificate may be useful, but it is not always sufficient. For a key ISMS role, the organization should be able to show not only that someone attended training, but that the person is suitable for the responsibilities assigned.
4. Clause 7.3, Awareness
Clause 7.3 is about awareness. Persons doing work under the organization’s control must be aware of the information security policy, their contribution to the effectiveness of the ISMS, including the benefits of improved information security performance, and the implications of not conforming with ISMS requirements. This is broader than annual security training. Awareness is not just knowing that a policy exists. It means that people understand enough to act appropriately in their role. The organization should therefore think carefully about who needs to be aware of what. A receptionist, developer, system administrator, HR employee, project manager, executive assistant, and external contractor may all need different awareness content. Some messages apply to everyone. Others must be adapted to the role.
At a basic level, all personnel should understand: That the organization has an information security policy, that information security is part of how the organization works. That they have responsibilities when using information and systems. That they should report suspected incidents or weaknesses.
That failing to follow ISMS requirements can have consequences. That good information security protects the organization, customers, colleagues, and other interested parties. Awareness of the information security policy. The information security policy is not meant to be a hidden document that exists only for auditors. Clause 7.3 requires people to be aware of it. This does not mean every employee must memorize the policy word for word. But they should understand its main purpose and what it means for their work.
For example, personnel should understand that the policy expresses management direction and commitment, that information must be protected according to its value and sensitivity, that security requirements apply to everyday work, and that exceptions or violations are not simply personal preferences.
Awareness of contribution Clause 7.3 also requires people to be aware of their contribution to the effectiveness of the ISMS. This is one of the most practical parts of Clause 7. Many employees do not see themselves as part of the ISMS. They think information security belongs to IT, compliance, or management. But the ISMS depends on many ordinary actions. A user who reports a suspicious E-Mail contributes to incident detection. A manager who reviews access rights contributes to access control. An HR employee who informs IT about a termination contributes to timely access removal. A project manager who involves information security early contributes to risk prevention. A developer who follows secure coding rules contributes to reducing vulnerabilities. A receptionist who follows visitor procedures contributes to physical security. A department head who supports training attendance contributes to competence and awareness. This is why awareness should be practical. People should be able to see how their own behaviour affects information security performance.
Awareness of implications:
The standard also requires awareness of the implications of not conforming with ISMS requirements. This should not be presented only as punishment. It should include the real effects of poor security behaviour. For example, failure to report a suspected phishing message may allow an attacker to compromise more accounts. Failure to follow classification rules may expose confidential information. Failure to remove access after a role change may allow unauthorized access. Failure to follow backup procedures may make recovery impossible. Failure to follow supplier review requirements may introduce unmanaged third party risk. Failure to document a change may make later troubleshooting, audit, or incident investigation much harder. In some cases, there may also be disciplinary, contractual, legal, or regulatory consequences. But the central message should be that nonconformity can damage the ISMS, weaken controls, increase risk, and harm the organization and its interested parties.
5. Awareness is not the same as a yearly slide deck
Many organizations reduce awareness to an annual online course. That may be part of the evidence, but it is rarely enough by itself.
Good awareness is continuous, role based, and connected to real work. It can include onboarding, periodic refreshers, short reminders, phishing simulations, management briefings, team discussions, posters, intranet articles, incident lessons learned, policy briefings, and targeted sessions for higher risk roles.
The point is not to overwhelm people. The point is to make information security understandable and relevant.
For example, a short-targeted briefing for managers on access reviews may be more effective than a generic annual training module. A practical explanation of how to report suspicious activity may be more useful than a long theoretical course on cyber threats. A focused session for project managers on when to involve information security may prevent risks much earlier than a generic policy reminder.
ISO/IEC 27000 identifies an effective information security awareness, training, and education programme as one of the critical success factors for an ISMS. Such a programme should inform employees and other relevant parties of their information security obligations and motivate them to act accordingly.
6. Practical implementation approach
A practical implementation of Clause 7.1 to 7.3 could follow a simple structure. First, identify ISMS activities and responsibilities. Look at the scope, risk assessment process, risk treatment plan, Statement of Applicability (SOA), objectives, operational processes, internal audits, and management review. Identify what work must actually be done. Second, determine the resources needed. This includes time, people, tools, budget, external support, and management involvement. Third, determine competence needs for key roles. Do not limit this to the Information Security Officer. Include risk owners, control owners, internal auditors, system administrators, managers, HR, legal, procurement, and others who affect information security performance.
Fourth, compare current competence with required competence. Where there are gaps, decide what action is needed. Fifth, define awareness needs. Separate general awareness for all personnel from role specific awareness for certain groups. Sixth, retain evidence. Keep records of resource decisions where relevant, competence evidence, training records, awareness activity records, and evaluations of effectiveness. Seventh, review and improve. Competence and awareness needs change when the organization changes, when risks change, when systems change, when incidents occur, or when audit findings reveal weaknesses.
7. Common mistakes
One common mistake is assuming that resources are adequate because the ISMS exists. An ISMS can be formally established and still be under resourced.
Another mistake is assigning responsibilities without checking competence. A risk owner, control owner, or internal auditor needs enough competence to perform the role properly. Another mistake is treating certificates as automatic proof of competence. Certificates can support evidence, but the organization should still consider whether the person can perform the assigned responsibilities effectively. Another mistake is using the same awareness content for everyone. General awareness is useful, but role specific responsibilities often require targeted communication and training. Another mistake is failing to evaluate effectiveness. The organization should not only ask whether training happened, but whether it worked. Another mistake is neglecting external personnel. Clause 7.3 refers to persons doing work under the organization’s control. Depending on the organization, this can include contractors, temporary staff, consultants, or outsourced personnel who affect information security.
8. What auditors will likely look for
For Clause 7.1, auditors will likely look for evidence that the organization has identified and provided the resources necessary for the ISMS. They may ask how ISMS responsibilities are resourced, whether planned activities are actually completed, whether risk treatment actions have owners and resources, and whether management review considers resource needs. For Clause 7.2, auditors will likely look for competence requirements, evidence that relevant people are competent, records of training or experience, actions taken to close competence gaps, and evaluation of those actions where applicable.
For Clause 7.3, auditors will likely ask how people are made aware of the information security policy, their role in the ISMS, and the consequences of not conforming. They may interview employees to see whether awareness is real. This is important. Awareness is often tested not only through records, but through conversations.
An auditor might ask an employee: Do you know where to find the information security policy?, What would you do if you suspected a security incident?,
How does information security relate to your role?, What rules apply when handling confidential information?, What happens if security requirements are ignored?, If employees cannot answer basic role relevant questions, the organization may have evidence of training, but still have weak awareness.
Conclusion
Clause 7 begins the support structure of the ISMS. It reminds the organization that information security does not run on documents alone. It needs resources, competent people, and awareness among those who work under the organization’s control. Resources make the ISMS possible. Competence makes it capable. Awareness makes it part of everyday behaviour. Together, these three requirements help move the ISMS from planning into practical operation. They also connect directly back to leadership and planning. Top management must ensure that resources are available, objectives must be achievable, risk treatment must be realistic, and people must understand their responsibilities.
In the next part, we will continue with Clause 7 by looking at communication and documented information. These two areas complete the support picture by showing how the ISMS communicates internally and externally, and how it controls the information needed to operate, demonstrate, and improve the system.