Go deeper
GRC + ISO 27001 — certification prep
Governance, risk and compliance, then ISO/IEC 27001:2022 clause by clause and the road to the certificate — with NIS2, DORA, CRA and the AI Act as of 2026. Every lesson has a quiz.
The reading track
- 01
GRC is not a department but the name for integrating governance, risk and compliance; kept apart, the three duplicate and contradict each other.
What Is GRC (Governance, Risk, and Compliance)? · OCEG (Open Compliance and Ethics Group) · 2002
The acronym was coined by OCEG in 2002, and its definition is less bureaucratic than it sounds: the integrated collection of capabilities that let an organisation reliably achieve objectives, address uncertainty and act with integrity. The load-bearing word is integrated. Governance sets direction and accountability, risk management says what can break that direction, compliance says what is mandatory along the way. Kept apart, they trip over each other: the same controls get inventoried three times, the same evidence is requested by three teams, and the board receives three dashboards that disagree. That is why GRC cannot be bought as a department or as a tool. It shows up in artefacts: one risk register, one set of controls with named owners, one list of legal obligations linked to those controls, and one report to the board. Everything else is a label stuck over the same three silos.
GRC (Governance, Risk, and Compliance) is the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity — to achieve Principled Performance.OCEG, «What Is GRC (Governance, Risk, and Compliance)?» — definiția de deschidere; acronimul a fost creat de OCEG în 2002
Why it matters Whoever treats GRC as three neighbouring departments pays three times for the same evidence and still cannot answer a single board question.
In full →Collapse ↑
Passage 1. Integration is not just shared registers; it flips the order of work: leadership questions come first, and governance, risk and compliance answer them together. In siloed practice it works backwards — each team builds its own inventory, then hopes someone will assemble it. A concrete example: launching a new product, the risk team assesses separately, the legal team checks separately, and the board hears two stories instead of one. An integrated organization starts from the question “can we launch this safely?” and gathers risks, obligations and controls as a single answer. Next step: what this looks like day to day, among people who never call it “GRC”.
Passage 2. Day to day, integration looks less like a program and more like small habits. People never say "GRC"; they simply stop asking for the same evidence twice. An accountant receiving an audit request asks whether the answer can also serve the security policy. A manager opening an incident immediately checks which legal obligations it triggers, not only at the end. A mundane example: when a payment vendor changes, one person gathers the risk assessment, the legal requirements and the control tests, then sends them together. The telltale sign is that nobody later discovers someone else had already done the same work. But these habits do not appear on their own; what makes them possible is the next question.
Passage 3. What binds these habits is not software but ownership: every control has a named person accountable for it. Without that, integration stays a drawing on paper. When a control has a single owner, the same test can serve many purposes, because someone is obliged to keep it alive. A concrete example: the control "access is reviewed quarterly" belongs to a specific team lead, and audit, security and legal all ask that one person, not three. If nobody signs up, each team builds its own copy and the silos come back to life. The named owner is the glue that keeps the register, obligations and controls in one place. But what happens when the organization grows and owners multiply? That is where integration is truly put to the test.
As an organization grows, owners multiply, and integration usually breaks on language. Each team names the same risk differently, so three lists about the same thing look like three different problems. The fix is not a department but a shared vocabulary: one risk, one obligation, one control each get a fixed name everyone uses. A concrete example: late payments to suppliers means exactly the same thing to procurement, legal, and finance, so their three registry entries merge without debate. Without that dictionary, even named owners quietly rebuild silos, only bigger. That leaves the question of what leadership actually does with the single picture this common language gives them.
Leadership now receives a single picture. But that unified view is not a report to read; it is a decision tool: it shows where risk, obligations and objectives collide. Concrete example: the budget is tight, and the picture shows one weak control covering both a legal duty and a major fraud risk. Money goes there, not to a project that merely looks good. Without the integrated view, each team asks for funds with its own story, and the choice becomes an auction. With it, the choice becomes a comparison on one scale. This is where Principled Performance appears: results that are not bought by compromising integrity. Next step: what happens when an unexpected event hits and decision time suddenly shrinks.
An unexpected event is the real test of integration, because decision time suddenly shrinks. In an integrated organization, leadership does not gather information during the crisis; it already has it, because the risk register, obligations and controls live in one place. A concrete example: a cloud provider goes down on a Thursday evening. Instead of three parallel meetings, the single picture immediately shows which clients are affected, which notification obligations kick in, and which backup controls exist. In siloed organizations, those same hours are spent hunting for who knows what. The crisis does not create the chaos; it only reveals it. And how decisions get made under pressure shows whether the integration is real or just a label.
Integration is not finished once built; it wears out if unmaintained. Registers, obligations and controls change constantly, and a stale single picture misleads as elegantly as three separate ones. Maintenance is not an annual project but a small, regular rhythm: who reviews what, when, and what triggers an update outside the calendar. Concrete example: a new data-protection law appears in spring; the obligation list is updated that same week, the matching control gets an owner, and the board picture reflects the change at the next meeting. Without that rhythm, integration becomes a snapshot of the past, not a picture of the present. The open question: who guards this rhythm when nobody explicitly demands it.
- 02
In 2024 the NIST framework promoted governance to a function of its own and placed it at the centre: it decides how the other five are applied.
The NIST Cybersecurity Framework (CSF) 2.0 · National Institute of Standards and Technology (NIST) · 2024
Until 2024 the NIST framework had five functions: identify, protect, detect, respond, recover. Version 2.0, published on 26 February 2024, added a sixth — GOVERN — and moved it to the centre of the wheel. It is not an extra heading but an admission: risk strategy, executive expectations, policy, roles and authorities, supply chain risk and oversight are not technical activities, yet they decide how well the technical ones get done. The consequence is unwelcome for teams that start with tools. If nobody has decided which objectives the organisation defends, who decides, and with what budget, then detection and response are optimised in a vacuum. The same idea underpins clause 5 of ISO/IEC 27001, leadership: top management does not support the system, it is accountable for it. An auditor hunting for governance evidence reads written management decisions with a date and an author, not monitoring screens.
GOVERN is in the center of the wheel because it informs how an organization will implement the other five Functions.NIST CSWP 29, «The NIST Cybersecurity Framework (CSF) 2.0» (26 februarie 2024), secțiunea 1 «CSF Core», explicația figurii 2
Why it matters At audit, governance evidence is a written management decision with a date and an author, not a technical dashboard.
In full →Collapse ↑
The good news is that GOVERN does not require a security department. The 2024 framework speaks to any organization, not only large ones. Governance, at its core, means deliberate decisions: what is worth protecting, who is accountable, how much we spend. A bakery with five staff can have governance if the owner writes down, in one file, which customer data they keep, who can access the till, and what to do when the ordering system fails. A huge group does the same thing, just with more pages. The difference is not size, but whether the decisions exist on paper rather than only in someone's head. That opens a practical question: what does the first governance decision a small organization can make this week look like?
The first governance decision a small organization can make is simple: choose who answers for security. It does not mean hiring a specialist. It means a written name next to a responsibility. In a small clinic, the owner-doctor writes down, signed and dated, that she decides what happens when the scheduling system goes down. That is governance in its simplest form. The 2024 framework takes the idea one step further: the decision must be showable to someone else. An auditor is not convinced by a screen full of alerts. They look for the document showing who decided what, and when. Monitoring shows that something is happening. A written decision shows that someone answered for it. Without that name, the framework's other functions remain activities with no owner. And once the name exists, the next question appears: what exactly is that person allowed to decide, and where do they stop?
- 03
Risk is measured against objectives, and whoever lacks a named owner for each risk has a spreadsheet, not risk management.
Guide for Conducting Risk Assessments (NIST SP 800-30 Rev. 1) · National Institute of Standards and Technology (NIST) · 2012
The definition in the NIST risk assessment guide (SP 800-30 Rev. 1, 2012) is useful precisely because it is dull: risk is a measure of how far an entity is threatened by a circumstance or event, as a function of adverse impact and likelihood of occurrence. ISO 31000:2018 says the same thing differently — the effect of uncertainty on objectives — and adds what the first phrasing lacks: risk is measured against objectives, not against assets. Three terms get confused constantly. Risk appetite is how much risk the organisation seeks in order to reach its objectives; it is a board decision, not a security team decision. Tolerance is the accepted deviation around that appetite, expressed as concrete thresholds that trigger a reaction. The risk owner is the person with the authority and accountability to treat it, meaning someone who can allocate budget and stop an activity. In ISO/IEC 27001:2022, clause 6.1.3 requires owners to approve the treatment plan and accept residual risks.
Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.NIST SP 800-30 Rev. 1, «Guide for Conducting Risk Assessments» (septembrie 2012), secțiunea 2.3 «Key Risk Concepts»
Why it matters The auditor does not ask which risks you have but who owns them and who accepted the residual risk; without names, clause 6.1.3 is not met.
In full →Collapse ↑
The step the card does not take yet is this: without written objectives, risk cannot be measured, because there is nothing to measure it against. NIST gives the formula, ISO gives the anchor — the effect of uncertainty on objectives. In practice, you first ask what the organization wants to achieve, then what could stop it. An online shop wants 24-hour delivery; so a courier outage is a risk, while a failure on a test server is just an event with no stake. The same failure becomes risk only when it hits an objective. Everything else follows from this: appetite, tolerance and the owner only make sense against that objective. But how does an organization decide how much risk it is willing to accept for its objective?
Passage 2: The answer to that question is risk appetite, and it is a leadership decision, not a security team's call. The board effectively states how much failure the organization can absorb on the way to its objective. Tolerance then translates appetite into concrete thresholds: if deliveries slip past eight hours, someone must react. Without a threshold, appetite stays a nice slogan on a poster. And thresholds without a named person who reacts remain just numbers on paper. Who should sign that name?
- 04
A certificate says that, on the audit date, a sample of evidence matched the requirements; it says nothing about the next day.
The Process of Security · Bruce Schneier · 2000
Schneier's sentence is a quarter of a century old and still the best objection to compliance treated as a destination. A certificate says that, on the audit days, a sample of evidence matched the requirements. The system that produced that evidence can be abandoned the next morning and the certificate stays valid until the next surveillance visit. The certificate is a photograph; security is the film it was cut from. Hence the practical test for any compliance programme: if a control only works when an audit approaches, the control does not exist, only audit preparation does. The signs are easy to spot: a year of access reviews all performed in the same week; logs collected retroactively; training completed by everyone in three days. ISO/IEC 27001 is built against exactly this pattern, because it requires measurement (9.1), internal audit (9.2), management review (9.3) and corrective action (10.2). That is cadence, not an event.
Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products.Bruce Schneier, «The Process of Security», revista Information Security, aprilie 2000 — paragraful de deschidere
Why it matters The surveillance auditor looks for traces of rhythm, and evidence crammed into the final week tells its own story.
In full →Collapse ↑
There is a cost difference between the two ways of thinking. A product is bought once, at delivery, and it ends there. A process is paid for monthly, in time and attention, and never ends. That is why many firms choose the photograph: it looks cheaper on paper. But the real price shows up at the incident, when the certificate stops nothing. Think of the window at home: a good lock bought once helps little if you never lock it at night. Security works the same way — the habit of locking, not the lock, is the protection. The next question follows naturally: if the process is the film, who keeps the camera running between audits?
A certificate has a strange property: it outlives the system that earned it. You could stop every monthly check tomorrow, and the paper stays valid until the next visit. That is why a surveillance auditor reads not only what the evidence shows, but when it was created. A familiar example: a student who crams only the night before the test gets the grade, but does not know the subject. Likewise, access logs all reviewed in the same week before an audit tell a story nobody wrote down explicitly. A steady rhythm, with small but frequent records, is the only sign that a control lives between checks. What remains to be seen is who in the company should own that rhythm as a daily responsibility.
The passages so far left a question: who owns the rhythm? Schneier's answer is uncomfortable: there is no natural owner. Security is a process, and a process has no single owner — it has participants. The accountant doesn't do security, yet follows an access policy. The admin doesn't do accounting, yet keeps the logs. The rhythm lives only if everyone sees their piece as part of their own work, not as a favor to the auditor. Hence the reverse test: ask someone outside the security team what they did for security this month. If the answer is "nothing, not my job," the process doesn't exist — only a small team preparing photographs. Think of cleaning in an apartment building: the stairwell stays clean only if every neighbor does their part, not if a cleaner comes before the manager's visit. What remains to see is what happens to the rhythm when people leave the company.
Passage 3 left the door open on people leaving. Here lies the real test of a process: if the rhythm lives only inside certain heads, it leaves with them. A true process does not depend on memory, but on a written, repeatable routine. The access review can be done by anyone, every month, if the steps are written down and the calendar exists. When the admin leaves, the new colleague opens the list and continues, without asking anyone how it was done. If only one person knows how logs are collected, the company does not have a control — it has a person. Think of grandma's recipe: if it is not written down, it dies with her. A written process survives change, the way the film keeps rolling when the camera operator is replaced. The next question is what to do when the written routine actually breaks.
Passage 4 left the question open: what do you do when the written routine actually breaks. This is where the process shows its real value. A good process does not claim nothing goes wrong; it defines what happens then. Who notices, who decides, who fixes, who records the lesson. The difference is not between firms without incidents and firms with incidents — incidents happen everywhere. The difference is between those that hide the hole and those that repair it and change the routine. Think of a burst pipe: a plumber who only plugs the hole leaves the problem to return; one who tells you why the pipe cracked changes how you maintain it. An incident handled this way becomes fuel for the process, not proof of failure. What remains to be seen is what a process that has learned looks like, compared to one that merely survived.
- 05
The three lines are not hierarchical floors but concurrent roles; the rule holding them together is that nobody assures their own work.
The IIA's Three Lines Model: An Update of the Three Lines of Defense · The Institute of Internal Auditors (IIA) · 2020
The model the Institute of Internal Auditors updated in July 2020 no longer speaks of lines of defence but of roles. The governing body sets direction and demands accountability. Management covers the first and second lines: the first delivers products and services and therefore owns the risks that come with them; the second brings expertise, monitoring and challenge — compliance, information security, quality. The third line is internal audit, providing independent and objective assurance on governance and risk management, reporting both to management and to the governing body. Two expensive confusions live here. The information security officer is second line: advising, monitoring, challenging, but never assuring their own work. And internal audit does not design controls or keep the risk register, or it forfeits its independence. The same rule governs certification: whoever implemented the system cannot audit what they implemented.
The internal audit function provides independent and objective assurance and advice on the adequacy and effectiveness of governance and risk management. It achieves this through the competent application of systematic and disciplined processes, expertise, and insight.The IIA, «The IIA's Three Lines Model: An Update of the Three Lines of Defense» (iulie 2020), Principiul 4 «Third line roles»
Why it matters Independence is not a formality: an opinion on your own project is worthless, and the certification body rejects the arrangement.
In full →Collapse ↑
The card says nobody gives assurance on their own work. Let's take the idea further: simultaneous roles only work if each knows when to stop. Whoever advises cannot then judge their own advice. Whoever builds a control cannot say whether the control is good. In a family, the person who cooked dinner is not the one who decides whether dinner was good enough for the guests. That is why internal audit designs nothing it will later assess. Independence is not a title, but a limit imposed on oneself. But what happens when roles overlap in practice, say when management asks internal audit to keep the risk register?
When internal audit keeps the risk register, the problem does not show up right away. The register looks fine, it is updated, everything runs smoothly. The damage appears a year later, when the same audit must judge whether the company's risks were correctly identified. Either way it evaluates, it is judging its own work, and the opinion becomes unusable for the governing body. It is as if the accountant who keeps the books also signed the report saying the books are correct. The solution is not for audit to refuse all help, but for the role to be written down clearly: who owns the activity, who checks it. That raises the next question: who actually decides these boundaries, and who oversees them?
- 06
Clause 9.1 does not ask for numbers but for a measurement plan: what, by which method, when and who — then who analyses the results.
Electrical Units of Measurement · William Thomson (Lord Kelvin) · 1883
Kelvin's sentence, from an 1883 lecture on electrical units, is usually misquoted as what you cannot measure you cannot manage. The original is more honest: without numbers, knowledge stays meagre, but it is not absent. The difference matters, because a programme that measures only what is easy to count ends up reporting activity instead of effect. Clause 9.1 of ISO/IEC 27001:2022 asks four questions and wants a documented answer to each: what is monitored and measured, by which methods, when the measurement happens and who performs it, then when the results are analysed and by whom. A performance indicator says how well a control is running, for instance the share of systems patched within the deadline. A risk indicator is forward-looking: it rises before the risk materialises. Confusing the two means reporting the past and calling it early warning.
I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind.«Electrical Units of Measurement», conferință la Institution of Civil Engineers, 3 mai 1883; Popular Lectures and Addresses, vol. 1 (1889), p. 73
Why it matters Clause 9.1 often fails at audit not because numbers are missing but because the method, the timing and the name of the measurer are missing.
In full →Collapse ↑
A measurement plan becomes real only when every answer in clause 9.1 carries a name attached. Not "measured periodically", but "Ana pulls the data on the first Monday of each month". Without a name, the plan is an intention; with a name, it is a verifiable obligation. A familiar example: a recipe that only says "cook until done" fails; the one that says who checks, with what, and when, works. The next step is to see what happens when someone measures, but nobody analyzes.
Measurement without analysis is a log, not a warning system. Clause 9.1 asks for the second half of the plan: who reads the results and when. Without it, indicators pile up like tram tickets kept and never checked. A familiar example: the bathroom scale gives you a number every morning, but if nobody decides what a month of increase means, the number changes nothing. Likewise, a report on patches applied on time only becomes useful when someone sets a threshold and what happens if it is exceeded. Analysis turns measurement into decision. What remains is to see which measurements deserve analysis: the ones describing the past or the ones announcing the future.
- 07
Documented information does not exist for the paper but because one's own memory is the most indulgent auditor anyone has.
Cargo Cult Science · Richard P. Feynman · 1974
Feynman's 1974 line describes, without meaning to, why management systems ask for documented information. Not because paper has value in itself, but because one's own memory is the most indulgent auditor anyone has. A process everyone agrees simply works that way cannot be contradicted by anything; a written process can be compared with what actually happened. From this come the two halves of the discipline: write what you do and do what you write. The first alone produces a shelf of procedures nobody follows, and every deviation becomes a nonconformity. The second alone produces good practice that cannot be demonstrated or handed on. Objective evidence is an artefact with a date, an author and content someone else can verify: a log, an approval, a test result, an attendance list. What cannot be shown to a stranger did not happen, as far as the audit is concerned.
The first principle is that you must not fool yourself—and you are the easiest person to fool.Richard P. Feynman, «Cargo Cult Science», discursul de absolvire la Caltech, 1974, publicat în Engineering and Science, iunie 1974
Why it matters At audit, the difference between an observation and a nonconformity is often just the existence of an artefact with a date and an author.
In full →Collapse ↑
Memory does not lie out of malice; it quietly rewrites the past each time. A week later, yesterday's decision already seems wiser than it was. A written artifact stops this slow rewriting. It is not just evidence for the auditor; it is an anchor against your own brain. Think of a meeting where everyone leaves convinced of slightly different things. The note sent afterward becomes the only real version. Feynman warned that you fool yourself most easily; the dated record is your defense. But what happens when you record something you never actually did?
Passage 1 ended with a question; here is the answer: a false record is not just a lie on paper, it contaminates the whole chain. Every dated artifact becomes the starting point for later decisions. If a test log says something that never happened, next month's colleague builds on an invented foundation. Feynman saw this in laboratories: slightly adjusted results, made with good intentions, that led an entire community down the wrong path. The everyday example: you fill in today's car checklist from memory, because surely you checked it yesterday. Tomorrow, someone drives off trusting a check that never happened. An honest record is hard to write; a false one is easy to write and costs everyone else. But what, in practice, stops you from writing honestly, when nobody is checking at that moment?
- 08
An ISMS is not a list of controls but the machinery that decides which controls are needed, puts them to work and checks whether they still fit.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
An ISMS — information security management system — is not a list of controls but the machinery that decides which controls are needed, puts them to work and checks whether they still fit. The standard says so directly in its introduction: the system preserves the confidentiality, integrity and availability of information by applying a risk management process. The Annex A controls, 93 of them, grouped in the 2022 edition into four themes — organisational, people, physical, technological — are the consequence of the risk assessment, not the starting point. The auditable requirements are clauses 4 to 10: context, leadership, planning, support, operation, performance evaluation, improvement. That structure is shared by every management system standard written since 2012, which has a practical upshot: ISO 9001, ISO 22301 or ISO/IEC 42001 for artificial intelligence use the same framing clauses. An organisation already running one of them adds the second scheme without rebuilding its policy, internal audit or management review.
The information security management system preserves the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed.ISO/IEC 27001:2022, Introducere, 0.1 «General»
Why it matters Whoever starts with Annex A builds a task list; whoever starts with clauses 4 to 10 builds the system the certification body will audit.
In full →Collapse ↑
The next step is deciding the scope. Before any risk or control, the standard asks you to state exactly what the system covers: which services, sites, and data. This choice is not formal. A scope too wide promises what you cannot sustain; one too narrow leaves out exactly the risks that matter. A concrete example: a firm with one online shop can declare only the sales platform, with payments and the customer database, not internal accounting. The scope then becomes the boundary where the auditor checks everything. A natural question follows: who, in the organization, answers for this boundary existing and being respected?
Passage 1 ended with a question: who answers for the boundary? Clause 5 gives the answer: top management. Not the IT department, but the people deciding budgets and priorities must show commitment and set a security policy. In practice, this changes where the conversation happens. If an online shop decides customer data matters, the decision is not made in the development team, but at the level that chooses between growth and protection. The auditor talks to leadership, not only to specialists. Security thus becomes a business decision, with an accountable owner. But whoever leads something must know which targets to aim for — and that is where planning in clause 6 comes in.
- 09
The scope is the only sentence a customer reads and the first page an auditor reads; it must survive both readings.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clause 4 asks for three things before any control. First, the internal and external issues relevant to the organisation's purpose and to the intended outcomes of the system. Then the interested parties and their requirements — customers, regulators, employees, suppliers — because a contractual requirement nobody identified becomes a nonconformity at the first audit. Only then comes the scope, at 4.3: the boundaries and applicability of the system, taking into account the issues from 4.1, the requirements from 4.2, and the interfaces with activities performed by other organisations. The classic mistake sits at 4.3, in both directions. A scope that is too narrow, one team or one product, passes the audit easily but convinces no customer who asks what exactly is certified. A scope that is too broad, declared before the processes exist, turns certification into a project that never ends. Amendment 1:2024, published in February 2024, added to 4.1 and 4.2 the duty to consider climate change as a possibly relevant issue.
The organization shall determine the boundaries and applicability of the information security management system to establish its scope.ISO/IEC 27001:2022, clauza 4.3 «Determining the scope of the information security management system»
Why it matters A scope cut only to pass the audit produces a certificate the sales team cannot use.
In full →Collapse ↑
The scope statement is not paperwork; it is a business decision written in audit language. It states exactly which processes, locations and data the certificate covers. Treat it like a product label: too vague, nobody buys; too optimistic, complaints come back. A simple example: a software company includes its customer support service in the scope, because that is where most sensitive data flows. If support stays outside, a client checking the certificate sees a hole. The next practical question: how do you draw that boundary without being either too timid or too bold?
Before drawing the boundary, the standard asks you to survey the terrain twice. First, the internal and external issues that can affect security: legislation, technology, market pressure. Second, the interested parties and what each demands: a client asking for encryption, a regulator asking for reports, a supplier with access to your systems. The scope is not chosen on the fly; it answers these requirements. A concrete example: a hosting provider with access to your database brings an obligation you cannot ignore just because it is not in your end-client contract. The next step follows naturally: what does the boundary look like when interfaces with others count too?
- 10
Clause 5 does not ask for a security department but for evidence that the people who decide the budget actually run the system: policy, objectives, resources, roles.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clause 5 has three subclauses and every one of them starts with "top management", not with "the organization". The wording is deliberate: at 5.1 the auditor asks for evidence that the people who decide budget and direction did something checkable — made sure the policy and the objectives exist and fit the strategic direction, integrated the requirements into the organization's ordinary processes, made resources available, promoted continual improvement. At 5.2 the policy has to suit the purpose of the organization, contain objectives or the framework for setting them, and carry two commitments: to satisfy applicable requirements and to improve continually. It exists as documented information, is communicated internally and is made available to interested parties as appropriate. At 5.3 roles are assigned and communicated, and two responsibilities are named outright: that the system conforms to the standard and that its performance is reported to top management. This is why stage 2 interviews are not held with the technical team alone.
Top management shall demonstrate leadership and commitment with respect to the information security management system by: ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization.ISO/IEC 27001:2022, clauza 5.1 «Leadership and commitment», paragraful introductiv și litera a)
Why it matters A clause 5 nonconformity cannot be fixed with a tool: it needs a management decision, so it is the slowest kind to close.
In full →Collapse ↑
Passage 1: Top management in 27001 means people with real power, not job titles. The auditor traces the chain from decision to effect. If the finance director approves the budget, they must be able to explain why security receives what it receives. A familiar example: at a logistics firm, the general manager signs the policy but cannot say what objectives it contains. A signature is not proof of leadership. The question that follows: what does a verifiable decision look like, not just a declared one?
A verifiable decision leaves traces in processes that already existed. The standard does not ask for a new structure, only that security requirements enter what the organization does anyway. In a pharmacy chain, this means the rules about access to electronic prescriptions appear in the pharmacist hiring procedure, not in a separate document nobody reads. Resources show up the same way: not in promises, but in the fact that the team has time and people for what was asked. And leadership periodically receives an answer to the simple question: is the system working or not? If all this exists, the next question is what the policy leadership approves must actually contain.
- 11
Risk assessment does not produce a list of fears but a comparison against criteria written in advance, which someone else can redo and get the same answer.
ISO/IEC 27005:2022 — Information security, cybersecurity and privacy protection — Guidance on managing information security risks · ISO/IEC · 2022
Clause 6.1.2 of ISO/IEC 27001:2022 asks for a process, not a spreadsheet. Item a) asks for written criteria: the risk acceptance criteria and the criteria for performing assessments. Item b) is the one that separates a serious method from improvisation — repeated assessments must produce consistent, valid and comparable results. Then come identification of risks to confidentiality, integrity and availability together with named risk owners; analysis, meaning the potential consequences, the realistic likelihood and the resulting levels of risk; and evaluation, meaning the first comparison against the criteria from item a) and the prioritization for treatment. The detailed guidance sits in ISO/IEC 27005:2022, the fourth edition, which contrasts two ways of identifying risk: the event-based approach, which starts from scenarios and the objectives at stake, and the classic asset-based approach, which starts from an inventory, threats and vulnerabilities. The first is faster and closer to the business, the second more complete and slower.
risk evaluation: process of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its significance is acceptable or tolerableISO/IEC 27005:2022, 3.2.6 «risk evaluation» — definiție preluată din ISO Guide 73:2009, 3.7.1, modificată («significance» a înlocuit «magnitude»)
Why it matters If two analysts in the same organization rank the same risks differently, item b) of clause 6.1.2 has already failed.
In full →Collapse ↑
Consistency is not just a competence test; it is what makes an assessment verifiable. If the result depends on whoever fills in the table, nobody can check anything. With criteria and method fixed in advance, the same process can be rerun a year later, and the differences mean something: the situation changed, not the analyst. Think of an online shop assessing the risk of payment downtime. If the method stays the same, a higher risk level than last year is a real signal, not a change of mood. But how do you build a method that yields the same results in different hands?
The answer to the previous question lies in choosing the starting point. ISO/IEC 27005:2022 puts two paths of risk identification side by side. The event-based approach starts from scenarios and from the objectives they would affect. The asset-based approach starts from an inventory, then ties threats and vulnerabilities to each item. The first is faster and closer to how leadership thinks. The second is slower, but covers corners a scenario can skip. Pick one, write it into the method, and two analysts will walk the same road. A restaurant taking online orders can start from the event "the ordering system goes down on a peak weekend". Or it can start from assets: the server, the app, customer data, each with its own threats. That same choice, written down in black and white, is what makes the result repeatable. But once risks are identified, who decides what is acceptable, and who carries the responsibility?
- 12
Controls come out of risk treatment, and Annex A is only the check that nothing was forgotten; the Statement of Applicability records both decisions.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Almost every beginner reads the order of 6.1.3 backwards. It does not start from Annex A. First the treatment options are chosen, taking account of the assessment results; then all controls necessary to implement the chosen options are determined — the standard says plainly that they may be designed by the organization or identified from any source; only then is the resulting list compared with Annex A, as a cross-check that nothing necessary has been omitted. The outcome is recorded in the Statement of Applicability, the one document that ties risks to controls. It says four things about each control: that it is necessary, why it was included, whether it is implemented or not, and why any Annex A control was excluded. A necessary control that is not yet implemented is allowed to appear there; what is not allowed is silence. Finally, the treatment plan and the acceptance of residual risk are approved by the risk owners.
produce a Statement of Applicability that contains: the necessary controls (see 6.1.3 b) and c)); justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the Annex A controls.ISO/IEC 27001:2022, clauza 6.1.3 litera d) — conținutul obligatoriu al Declarației de aplicabilitate
Why it matters The Statement of Applicability is the first document asked for at stage 1 and the only one that shows whether the system really started from risk.
In full →Collapse ↑
The previous passage showed the right order: risks, options, controls, then the cross-check with Annex A. The next step is understanding what happens when that comparison finds a difference. If a control from Annex A does not appear on your list, that is not automatically a mistake. It can be excluded, but only with a justification showing why your risks do not demand it. For example, a company with no physical office can explain why a control about office-area security has nothing to protect. What is not allowed is leaving the control out silently, with no written reason. The justification is not a formality for the auditor; it is your own thinking put on paper. And when the justification is missing, the auditor can no longer see where the system started from. But what happens to a control you found necessary, yet have not implemented yet?
A necessary control that is not yet implemented is allowed, under one condition: it must be recorded as such in the Statement of Applicability. The document thus becomes a map of the work still to be done. A control marked as necessary but not implemented shows a conscious decision, not neglect. For instance, a small firm knows it needs a strong password policy but will only write it next month; in the statement, its status is honest. An auditor sees the difference between a plan in progress and a shell game. What unbalances the system is silence: a control missing from the list without a reason, or one declared implemented when it is not. The statement must tell the truth about every line, even when the truth is uncomfortable. The question that remains is who signs off, in the end, on these decisions and on the risk left over after them.
- 13
Objectives must be measured and communicated, changes must be planned, and competence must be evidenced: clauses 6.2, 6.3 and 7 turn intent into evidence.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clause 6.2 asks for objectives that can be checked: consistent with the policy, measurable if practicable, taking account of applicable requirements and of the results of risk assessment and treatment, monitored, communicated, updated and available as documented information. Their planning answers five questions on top of that: what will be done, with what resources, who is responsible, when it will be completed and how the results will be evaluated. "Raise the level of security" does not survive that filter. Clause 6.3 is new in the 2022 edition and is a single sentence, but it is auditable: a change to the system — a new site, a new cloud provider, a reorganization — carried out in a rush becomes a finding. Clause 7 supplies the rest: resources (7.1), competence determined, ensured and evidenced with the effectiveness of actions evaluated (7.2), awareness of the policy, of one's own contribution and of the consequences of not conforming (7.3), planned communication (7.4) and control of documented information (7.5).
When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.ISO/IEC 27001:2022, clauza 6.3 «Planning of changes» — clauză nouă în ediția din 2022
Why it matters Most minor nonconformities at a first audit sit in clause 7: competence and awareness evidence that was never retained.
In full →Collapse ↑
The three clauses really form one habit: never do anything important without being able to show later how you decided, who was prepared, and what came of it. Measuring objectives is not bureaucracy; it is the organization's memory. If the objective is fewer access incidents, you must say who counts them, how often, and where the result is kept. A simple example: when the office moves, who signs that staff were trained on the new access controls? Without that signature, the change looks rushed. An audit does not ask whether you care; it asks what you can show. And the most commonly missing evidence is not the policy, but the record of people's preparation. Next step: what a good competence record looks like in practice.
- 14
Clauses 6.1.2 and 6.1.3 ask for the method, while 8.2 and 8.3 ask for it to be run: the same words, a different verb and different evidence.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clause 8 is where the system actually runs. At 8.1 the organization plans, implements and controls the processes needed to meet requirements and to implement the actions determined in clause 6, retains documented information showing the processes were carried out as planned, controls planned changes and reviews the consequences of unintended ones. This is also where outsourcing sits: externally provided processes, products or services relevant to the system must be determined and controlled. They do not have to be certified, they have to be controlled. The classic exam confusion is between 6.1.2 and 8.2. The first requires that a risk assessment process exist, defined and applied; the second requires that the process actually be run, at planned intervals and on significant changes, with the results retained. The same pair exists for treatment: 6.1.3 defines the process, while 8.3 requires the plan to be implemented and the results to be retained.
The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in 6.1.2 a).ISO/IEC 27001:2022, clauza 8.2 «Information security risk assessment», prima propoziție
Why it matters A flawless clause 6 file with no clause 8 evidence describes a system that was designed, not one that runs.
In full →Collapse ↑
The 6-8 pair changes how you read any requirement in the standard. You no longer ask only "what must exist", but "who ran it, when, and what was left behind". An auditor doesn't stop at the written procedure; they follow the trail left by execution. Think of a baking recipe: having it written down is not the same as an oven smelling of fresh bread and a notebook where you logged the temperatures. The difference between the two clauses is, in fact, the difference between intention and deed. And that trail has a structure worth unpacking: what exactly must be kept as evidence, and what makes it convincing?
Passage 2 looks at what execution leaves behind. Under 8.2, the evidence is not just the final report, but the fact that the assessment used the criteria fixed in 6.1.2: what you consider acceptable risk, what scale you measure on. If the criteria changed between two runs, the report must show it. A concrete example: in recruitment, the final shortlist is not enough; what matters is the scoring grid actually applied and who signed it. Under 8.3, the trail is the treatment plan turned into decisions: risks accepted, modified or transferred, each with proof of the action. And 8.1 adds an easily overlooked requirement: external providers. A cloud service or an outside accountant holds processes belonging to your system; they must be determined and controlled, not just named in a contract. One question remains: what happens when execution reveals that the plan itself was wrong?
- 15
Clause 9 asks for three different things: measure, audit yourself with an independent eye, and put the results on management's table.
ISO 19011:2026 — Guidelines for auditing management systems · ISO · 2026
At 9.1 the organization decides what it monitors and measures, by which methods, when and by whom, and the chosen methods have to produce comparable and reproducible results to be considered valid. At 9.2 an internal audit programme is required — frequency, methods, responsibilities, planning and reporting requirements — built with the importance of the processes and the results of previous audits in mind; auditors must be selected so as to ensure the objectivity and impartiality of the process. At 9.3 top management reviews the system against a fixed list of inputs: the status of previous actions, changes in context and in interested parties' requirements, system performance, audit results, fulfilment of objectives, risk assessment results and opportunities for improvement. The method guidance is ISO 19011, whose fourth edition appeared in May 2026 and replaces the 2018 edition; being a guidance standard, it applies immediately, with no transition period.
Independence is the basis for the impartiality of the audit and objectivity of the audit conclusions. Auditors should be independent of the activity being audited wherever practicable and should in all cases act in a manner that is free from bias and conflict of interest.ISO 19011:2026, 4.6 «Independence» — ediția a patra, publicată în mai 2026, care înlocuiește ISO 19011:2018
Why it matters Whoever implements a process cannot audit it: independence is what makes an internal audit a check rather than a confirmation.
In full →Collapse ↑
Clause 9 does not ask for three parallel duties, but for a chain where each link feeds on the previous one. The data measured under 9.1 becomes the raw material the internal auditor verifies under 9.2. The audit findings then enter, under 9.3, the fixed input list of the management review, alongside performance and risks. If one link weakens, the whole chain produces only paperwork. Think of a restaurant: the recipes are the measurements, the kitchen check is the audit, and the owner's weekly meeting is the management review. If the cook who prepared the dishes also checks them alone, the check becomes confirmation, not verification. The question that follows: where does this chain actually break in your organization?
- 16
A correction fixes the incident, a corrective action fixes the reason it was possible; the standard asks for both, and the auditor tells them apart.
Out of the Crisis · W. Edwards Deming · 1986
In the 2022 edition the order changed: 10.1 is continual improvement and 10.2 is nonconformity and corrective action. The requirement has two halves. First you react to the nonconformity: control it, correct it and deal with the consequences. Then you evaluate whether action is needed to eliminate the causes, so that it does not recur or occur elsewhere — you review the nonconformity, determine its causes and check whether similar nonconformities exist or could occur. Finally you review the effectiveness of the corrective action and change the system if necessary. The nature of the nonconformities, the actions taken and their results are retained. A lost laptop is replaced: that is the correction. The reason full-disk encryption was not enforced on every laptop is removed: that is the corrective action. The step skipped most often is the last one, the effectiveness review — without it the ticket is closed but the nonconformity is not.
Quality comes not from inspection, but from improvement of the production process.Out of the Crisis (MIT Press, 1986), cap. 2, p. 29 — comentariul la Punctul 3 al celor 14 puncte, despre renunțarea la dependența de inspecție
Why it matters The same finding coming back year after year means only corrections were made, and that is the commonest reason a nonconformity escalates.
In full →Collapse ↑
Deming saw in factories the same gesture we see in offices today: fix it fast, then everyone breathes a sigh of relief. Correction creates the feeling that something is finished. But if the process stays unchanged, the same problem returns, just with a new date. Think of a colleague who keeps forgetting their badge at the entrance. You open the door for them every time: correction. Install automatic badge reading into the access flow: corrective action. The difference is not severity, but the question: did we repair only the incident, or also the reason it was possible? Auditors do not demand that you have no nonconformities. They demand you can show both halves, each with evidence. And the hardest evidence remains the last one: that the corrective action actually worked.
- 17
The 2022 Annex A holds 93 controls in four themes and is a cross-check list, not a project plan you must tick off in full.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
The 2022 edition restructured the annex: from 114 controls in 14 clauses there are now 93, grouped in four themes — organizational (37), people (8), physical (14) and technological (34). Eleven are entirely new: threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23) and secure coding (8.28). The implementation guidance lives in ISO/IEC 27002:2022, which gives every control five attributes for filtering: control type, information security properties, cybersecurity concepts, operational capabilities and security domains. The attributes are a sorting tool, not extra requirements. And 27002 is guidance: nobody gets certified against it.
The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.ISO/IEC 27001:2022, clauza 6.1.3 c), NOTA 3
Why it matters Projects that start by implementing all 93 controls spend heavily on risks they do not have and still fail at the Statement of Applicability.
In full →Collapse ↑
The right order is the reverse of instinct: risks first, controls second. Annex A works as a dictionary of options, not a shopping list. From it you pick only what answers a real risk your organisation faces. The rest goes into the Statement of Applicability with a justification for exclusion, and that is perfectly legitimate. Example: a company without its own office has little to manage under the physical theme beyond employees' laptops. The standard explicitly says the list is not exhaustive, so you can add controls of your own. In short: Annex A answers "what exists", not "what you need". The next step is seeing how you decide, control by control, what goes in and what stays out.
How do you decide, control by control? The 2022 edition restructured the list: 93 controls in four themes, from organization down to technology. Eleven are new, including cloud security, data deletion and secure coding. The signal is clear: the list tracks how work is done today, it is not a fixed, timeless set. But it only says what exists, not how to apply it. The practical detail lives in ISO/IEC 27002, which adds filtering attributes to each control — control type, operational capabilities, security domains. They are a sorting tool, not extra requirements. And 27002 is only guidance: nobody gets certified against it. A concrete example: if you pick the cloud control, the attributes point you straight to its implementation guidance, not through the whole list. Next step: what do you do with risks for which no control on the list is enough.
- 18
A useful gap analysis compares the requirement with the evidence that exists, not with intent: what the standard asks, what you have, who closes the difference and by when.
The Art of War · Sun Tzu, traducere Lionel Giles · 1910
The standard explicitly requires documented information in fourteen places: the scope (4.3), the policy (5.2), the risk assessment process (6.1.2), the risk treatment process and the Statement of Applicability (6.1.3), the objectives (6.2), evidence of competence (7.2), evidence that processes were carried out as planned (8.1), the results of risk assessments (8.2), the results of treatment (8.3), monitoring and measurement results (9.1), the internal audit programme and its results (9.2), the results of management reviews (9.3) and, at 10.2, the nature of nonconformities, the actions taken and their results. On top of those come the documents required by the controls kept in the Statement: topic-specific policies, the inventory of information and other associated assets, acceptable use rules and the rest. A good gap analysis has one line per requirement and three columns: what the standard asks, what evidence exists today and where, then the verdict — conforming, partial or absent, with an owner and a deadline. Percentages without owners close nothing.
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.The Art of War, traducerea Lionel Giles (1910), cap. III «Attack by Stratagem», §18
Why it matters Stage 1 is most often failed not for lack of controls but for lack of the documented evidence the standard names outright.
In full →Collapse ↑
A gap analysis fails quietly when the evidence exists only on paper. A signed policy means nothing if nobody follows it. Check the actual practice, not just the file in the folder. Ask people how they really work and compare the answer with the document. If the two don't match, the gap is bigger than the table says. A simple example: the rule says access is reviewed quarterly, but the last extract is two years old. The requirement is then partial, not compliant, no matter how well the policy is written. The next step: how to turn these findings into actions someone actually finishes.
A gap table only becomes useful when every line has an owner with real decision power. Not the person who knows the most about the topic, but the one who can allocate time and money. A risk assigned to someone without a budget stays on paper. The deadline must be a verifiable date, not urgent, not soon, not this quarter. And a partial status is more valuable than an optimistic conformant one: it says precisely what is missing. A concrete example: instead of access is reviewed, write that Ana from operations will deliver access extracts for all systems by a specific date, with a pool of hours approved by her manager. If the date passes without delivery, the gap has not vanished, it has only moved. Then the question changes: who checks that the deadline was met, and what happens when it was not.
- 19
Certification is not an event but a three-year cycle: two stages at the start, surveillance every year, recertification at the end.
Remarks on Signing the Intermediate-Range Nuclear Forces Treaty · Ronald Reagan · 1987
The certification audit comes in two stages. Stage 1 looks at documentation and readiness: the scope, the policy, risk assessment and treatment, the statement of applicability, evidence that the internal audit and the management review actually happened. Its output is not a grade but the plan for stage 2 and the list of things that would block it. Stage 2 checks implementation: records from the elapsed period are requested, people inside the processes are interviewed, what is written is compared with what is done. After the certificate come annual surveillance, on a sample of processes and controls, and full recertification every three years. The body issuing the certificate is itself accredited against ISO/IEC 17021-1, in Romania by the national accreditation body RENAR; a certificate with no accreditation behind it is paper, not recognition. For the same reason of independence, whoever implemented the system cannot also audit it.
We have listened to the wisdom in an old Russian maxim. And I'm sure you're familiar with it, Mr. General Secretary, though my pronunciation may give you difficulty. The maxim is: Dovorey no provorey — trust, but verify.Ronald Reagan, cuvântare la semnarea Tratatului privind forțele nucleare cu rază intermediară, Casa Albă, 8 decembrie 1987 — arhiva Bibliotecii Prezidențiale Reagan
Why it matters The order of the stages tells you where time is lost: entering stage 2 without records from the elapsed period delays the certificate rather than speeding it up.
In full →Collapse ↑
Reagan borrowed a Russian proverb about trust and verification. The idea goes further: verification is not a one-off gesture but a rhythm. Certifying a management system works the same way. You do not look at something once and call it done; you set up a cycle with deadlines known from the start. Think of the medical check for a driving licence: you do not prove once and for all that you can see, you return at fixed intervals. The difference is that here the cycle has structure: preparatory stages, then yearly checks, then a full restart. The rhythm exists precisely because trust wears out and systems change. The natural next question is what actually happens at each of these moments in the cycle.
The cycle begins with a split many people miss: certification is not requested all at once, but in two stages. The first does not hunt for flaws in practice; it reads the paperwork and the readiness. It checks that the scope is defined, that policy and risk assessment exist, that the internal audit and management review actually happened. The result is not a grade but a plan: what stage two will examine and what could block it. It is like visiting the architect before a renovation: nothing gets demolished, but you learn where the load-bearing walls are. Skipping stage one means entering stage two blind. And stage two demands something else: records from the elapsed period and people describing how they work. What happens once the certificate is up on the wall?
- 20
An audit finding is not an opinion: it is a departure from a requirement, resting on something verifiable, and its severity decides whether the certificate can still be issued.
ISO 19011:2018 — Guidelines for auditing management systems · ISO · 2018
Findings come on four rungs. An opportunity for improvement is not a departure, it is a suggestion. An observation flags something that still meets the requirement but is heading the wrong way. A minor nonconformity is an isolated lapse against a requirement. A major nonconformity is something else: the complete absence of a requirement, a systemic breakdown, or a failure that casts doubt on the system's ability to achieve its outcomes. The difference is not one of tone but of consequence — an open major blocks the certification decision. The response has four parts, in this order: the correction, meaning the repair of the case found; root-cause analysis; the corrective action, which changes the process so the situation cannot recur; and a committed deadline. Whoever sends only the correction gets the finding back. Every finding rests on objective evidence — a record, a statement of fact or other relevant and verifiable information — not on the auditor's impression.
Audit evidence: records, statements of fact or other information which are relevant to the audit criteria and verifiable.ISO 19011:2018, clauza 3.8 — definiția dovezii de audit (platforma de consultare ISO e randată în JavaScript și a răspuns 403 la verificare)
Why it matters Confusing minor with major costs weeks: a major is not closed with an excuse but with a demonstrated change of process.
In full →Collapse ↑
The next step is how the finding is written. A good finding has three parts: the requirement that was breached, what was observed, and the evidence linking the two. If one is missing, the company does not know what to fix. Tell the auditor: the requirement says every workstation must hold the current instruction. At workstation two, the instruction is from last year, and this is visible in the file checked today. The company knows exactly what to correct. A vague phrasing, like the procedure is not properly followed, is not a finding; it is an impression dressed up in technical language. Which raises the question: who checks that the company's answer actually covers the requirement in the finding?
- 21
Since 1 November 2025 there are no certificates on the 2013 edition: every audit runs against 2022, with an Annex A of 93 controls and climate in the context.
IAF MD 26:2023 — Transition Requirements for ISO/IEC 27001:2022 · International Accreditation Forum · 2023
The transition is over. The mandatory document of the international accreditation forum, IAF MD 26:2023, set a three-year window from the publication of the 2022 edition and said without hedging that certifications on the 2013 edition expire or are withdrawn at its end — 31 October 2025. In 2026 the question is no longer how you transition but what you can show against the current edition. What changed concretely: clause 6.3 requires planning of changes to the system; clause 10 reversed its order, with continual improvement now ahead of nonconformity and corrective action; Annex A went from 114 to 93 controls, restructured into four themes, with eleven new controls, among them threat intelligence, cloud security, configuration management, data masking and secure coding. Amendment 1:2024 added to clauses 4.1 and 4.2 the duty to consider climate change as a relevant issue of the context.
All certifications based on ISO/IEC 27001:2013 shall expire or be withdrawn at the end of the transition period.IAF MD 26:2023, Issue 2 (emis 15 februarie 2023), §4.2 «CAB Actions» — acțiunile organismului de certificare
Why it matters A compliance plan still talking about 114 controls is written for a standard nobody audits any more.
In full →Collapse ↑
The expiry of 2013 certificates is not just a calendar date; it changes the organization's role. Before, the transition was a project with a deadline. Now, the 2022 edition is simply the standard you live with day to day. The difference shows in practice: you no longer prepare a migration file, you maintain a system that already speaks the new language. Think of a shop that swapped an old cash register for a digital one. At first, the transition was the event. Afterwards, nobody talks about the switch; what matters is that the receipt comes out right every day. Same here: the useful question in 2026 is what live evidence you can show an auditor, not what you once did to get across. And that raises a natural question: who actually checks that the organization is on the right edition?
Passage 1 asked who checks the edition. The answer is the accreditation chain: certification bodies answer not only to clients but to accreditation entities, which follow the rules of the international forum. The transition document gave them the deadline and required them to plan audits accordingly. So the pressure does not come from the auditor at your door, but from the structure that authorizes that auditor. A familiar example: at a car inspection, your vehicle is not checked by any mechanic, but by a licensed station following procedures fixed by the state. If the station fails to comply, it loses its license. Similarly, a certification body still issuing certificates on the old edition would put its own accreditation at risk. Which raises the next question: what exactly in the new standard is now scrutinized more closely?
- 22
NIS2 moves security out of the technical basement and into the boardroom: the measures become legal duties, and management is personally answerable for them.
Directiva (UE) 2022/2555 privind măsuri pentru un nivel comun ridicat de securitate cibernetică în Uniune · Parlamentul European și Consiliul Uniunii Europene · 2022
Directive (EU) 2022/2555, NIS2 for short, is transposed in Romania by Emergency Ordinance 155/2024, published in the Official Gazette no. 1332 of 31 December 2024; the competent authority is the National Cyber Security Directorate. Covered entities split into essential and important, and the difference lies in the supervisory regime and the ceiling on fines, not in the set of measures. Article 21 requires appropriate and proportionate measures, on an all-hazards approach, and lists ten minimum categories: risk analysis, incident handling, continuity, supply chain security, secure acquisition and development, assessment of effectiveness, cyber hygiene and training, cryptography, human resources security and access control, multi-factor authentication. Article 23 sets the tempo: early warning within 24 hours, notification within 72, final report within one month. Article 20 says the management body approves the measures and can be held liable.
Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services.Directiva (UE) 2022/2555 (NIS2), art. 21 alin. (1), primul paragraf — măsuri de gestionare a riscurilor de securitate cibernetică
Why it matters The ten categories of Article 21 map almost one to one onto the Annex A controls, so a certified system becomes the skeleton of compliance rather than a parallel project.
In full →Collapse ↑
The card says NIS2 moves accountability into the boardroom. The next step: the law does not impose a fixed package of measures, but an outcome. Article 21 requires measures that are appropriate and proportionate to each entity's risks. So a small firm holding sensitive data can face heavier duties than a large one with low risk. Proportionality is judged by what would happen if systems went down, not by headcount. Example: a medical lab with twenty staff that stores test results must protect that data as a core business asset, because patients depend on it. Leadership must therefore first understand its own risks before choosing any tool. How is this understanding of risk actually built?
- 23
DORA asks not for a security management system but for demonstrated resilience: that it holds, that you know who holds your keys, that you tested it.
Regulamentul (UE) 2022/2554 privind reziliența operațională digitală a sectorului financiar · Parlamentul European și Consiliul Uniunii Europene · 2022
Regulation (EU) 2022/2554 applies directly to financial entities from 17 January 2025 and rests on five pillars: management of information and communication technology risk, incident handling and reporting, digital operational resilience testing, third-party technology provider risk, and information sharing on threats. Two requirements have no equivalent in a classic management system. The first is the register of information: every contractual arrangement for technology services, with the function it supports, in a form the supervisor can demand in full. The second is advanced threat-led testing, mandatory at least once every three years for entities identified by the competent authority — a simulation against live systems, not a vulnerability scan. Above them, providers designated as critical fall under the direct oversight of the European supervisory authorities. A certified system covers the first pillar well and much of the second; the rest asks for new things.
Financial entities shall have in place an internal governance and control framework that ensures an effective and prudent management of ICT risk, in accordance with Article 6(4), in order to achieve a high level of digital operational resilience.Regulamentul (UE) 2022/2554 (DORA), art. 5 alin. (1) — guvernanță și organizare
Why it matters Whoever thinks a certificate covers DORA discovers at the first inspection that the register of information and threat-led testing were never in its scope.
In full →Collapse ↑
DORA pushes accountability upward, into the boardroom. It is not IT that signs off that the system is resilient; the entity's leadership answers personally for it. Resilience is treated as a state that must be proven continuously, not a document approved once a year. In practice, a board member should be able to say, without opening a report, who has access to critical systems and when the last attack scenario was tested. It is like in an apartment building: you do not look for the elevator's installation papers, but for the current inspection record. This raises the practical question: what does it actually mean for a board to demonstrate resilience, not merely declare it?
- 24
From 11 September 2026, any product with digital elements sold in the Union carries reporting duties for actively exploited vulnerabilities, with a 24-hour clock running.
Regulamentul (UE) 2024/2847 privind cerințe orizontale de securitate cibernetică pentru produsele cu elemente digitale · Parlamentul European și Consiliul Uniunii Europene · 2024
Regulation (EU) 2024/2847, the cyber resilience act for short, moves liability onto the manufacturer: the product must be designed, developed and produced against the essential requirements of Part I of Annex I, and the risk is assessed and documented across the whole support period. In practice that means shipping with no known exploitable vulnerabilities, secure default configuration, security updates and a software bill of materials covering top-level dependencies. The calendar is tiered. The reporting duties of Article 14 apply from 11 September 2026: an actively exploited vulnerability is announced by an early warning within 24 hours, a notification within 72 hours and a final report within 14 days. The rest of the regulation applies from 11 December 2027. For anyone who already holds a certified system, the secure development controls of Annex A, 8.25-8.28, from the secure life cycle to secure coding, are exactly where to start.
When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.Regulamentul (UE) 2024/2847 (actul privind reziliența cibernetică), art. 13 alin. (1) — obligațiile fabricantului
Why it matters The 24-hour deadline is not negotiated during the incident: either a vulnerability handling process exists that can meet it, or it does not.
In full →Collapse ↑
The card says when the clock starts. The next step is what happens within those 24 hours, before anything is certain. The early warning does not require a full analysis, only the signal that a vulnerability is being actively exploited and that your product is affected. This changes the order of work: first you notify, then you investigate. A classic security process waits for a complete diagnosis before communicating; here, communication comes first. Think of a connected fridge or a home security camera: if the manufacturer learns on a Monday that someone is exploiting it, the clock has already started. So the practical question is not "do we have a procedure?" but "can we send a correct warning overnight?". And that depends on who in the company can decide without waiting for the boss the next morning.
Passage 1 stopped at who can decide overnight. Passage 2 looks at what comes after: the 72-hour notification and the final report. The early warning only says "something is happening". The 72-hour notification must bring the first facts: what is affected, how it is exploited, who is touched. So the firm needs a ready-made channel to the security authority, not one found under pressure. Think of a pizza chain: if you do not know in advance whom to call, the order loses its most expensive time anyway. And the final report, at 14 days, closes the story with what was caused and what was fixed. That means investigation, communication and remediation must run in parallel, not in sequence. The natural next question: who actually receives these notifications, and what do they do with them?
Passage 2 asked who receives the notifications. The answer is designed as a filter, not a queue: the manufacturer sends to a designated contact point, and the information reaches the European incident response network and the market surveillance authorities. The point is not only to know who got hit, but to see the whole picture. If several manufacturers report the same vulnerability in a shared component, the problem reveals itself as systemic. Think of a building where several neighbours report the same leak: separately, each looks like an accident; together, they point to a broken main pipe. For the manufacturer, this means reporting is not an isolated compliance act, but one piece of a Union-wide early warning system. The next question: what happens when the vulnerability is not yours, but a supplier's from your component list?
- 25
An artificial intelligence management system is not built beside the security one but inside it: the same clauses, a different risk register.
Regulamentul (UE) 2024/1689 de stabilire a unor norme armonizate privind inteligența artificială · Parlamentul European și Consiliul Uniunii Europene · 2024
Regulation (EU) 2024/1689 applies in tiers. The prohibited practices and the general provisions apply from 2 February 2025, the duties for general-purpose models from 2 August 2025, and the regulation's general application from 2 August 2026. For the high-risk systems of Annex III, the "digital omnibus" package deferred the obligations to 2 December 2027 — the state of play in September 2026. Article 9 requires a risk management system established, implemented, documented and maintained across the whole life cycle of the high-risk system: an iterative process, not a folder. This is where the harmonized structure of management system standards pays off. ISO/IEC 42001:2023, the standard for artificial intelligence management systems, uses the same clauses 4-10 as ISO/IEC 27001, so context, roles, internal audit and management review are run once. What is added is specific: the inventory of systems, the impact assessment on people, training data, human oversight.
A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.Regulamentul (UE) 2024/1689 (regulamentul privind inteligența artificială), art. 9 alin. (1) — sistemul de management al riscurilor
Why it matters Whoever treats artificial intelligence compliance as a separate project pays twice for exactly the same management clauses.
In full →Collapse ↑
Earlier passages showed that the two systems share the same management clauses. But sharing clauses does not mean one document. Article 9 requires its own risk register for artificial intelligence, separate from the security one. A security risk says: someone steals your customer data. An artificial intelligence risk says: your lending system systematically rejects applications from one neighbourhood. Both live in the same annual review, at the same table, but with different vocabulary. In practice, you meet the team once and discuss two registers. Whoever merges them loses each one's specificity; whoever fully separates them doubles the meetings. The next step: who should own each register in the organisation.
- 26
In 2026 compliance moves from the annual folder to continuous evidence, and certification becomes the platform several frameworks rest on at once.
Recomandarea (UE) 2024/1101 privind o foaie de parcurs coordonată de punere în aplicare a tranziției la criptografia post-cuantică · Comisia Europeană · 2024
Three lines are already visible. First: evidence collects itself. A control described as prose and checked once a year is replaced by a control expressed as an executable rule that produces the record that it worked; the auditor reads a history, not a screenshot. Second: the supply chain. Controls 5.19-5.23 of Annex A and Article 21(2)(d) of NIS2 ask the same thing — know what your suppliers risk, and write it into the contract. The threat landscape published in 2025 by the European cybersecurity agency analysed 4,875 incidents between July 2024 and June 2025, with phishing the dominant intrusion vector, in 60% of cases. Third: post-quantum cryptography. The coordinated roadmap of June 2025 asks that the transition start by the end of 2026 and that critical infrastructures migrate no later than the end of 2030, onto the algorithms standardised in August 2024 by the American institute of standards and technology.
Member States should consider migrating their current digital infrastructures and services for public administrations and other critical infrastructures to Post-Quantum Cryptography as soon as possible, inducing a fundamental shift in cryptographic algorithms, protocols and systems.Recomandarea (UE) 2024/1101 a Comisiei din 11 aprilie 2024, considerentul (5) — migrarea la criptografia post-cuantică
Why it matters Evidence produced once and read by several frameworks is the only way the number of audits can grow without the effort growing with it.
In full →Collapse ↑
Continuous evidence changes the order of work. Before, you built the file when the audit arrived. Now the control is written as a rule, the rule runs daily, and it leaves traces. The shift is not technological but about timing: the question is no longer what you did in December, but what happened on Tuesday at three. A concrete case: an admin account password expires automatically after ninety days. The rule enforces it on its own and records the enforcement. The auditor sees in the history that no password lived longer. The same history then serves NIS2, ISO, or a customer's requirements, with no rework. Next step: what happens when two frameworks demand the same control, worded differently.
The next step is mapping. Each framework has its own language, but the requirements overlap. For example, supplier risk management appears both in Annex A, in the controls about supplier relationships, and in NIS2, in the article on supply chain security. The content is nearly identical: know what your suppliers can affect and put that into contracts. If you write the control once, as an executable rule, then tag it with the references from each framework, one collection feeds several answers. A concrete case: a major client's yearly questionnaire asks for supplier policies; you pull them from the same history that already serves the auditor, instead of rebuilding them. Here the limit appears: some requirements, like migrating to post-quantum cryptography, cannot be reduced to one shared control. Next step: what a control does when the requirement is a transition, not a state.
- 27
Beauty is not decoration but an ambivalent moral force: it can elevate or corrupt, and the struggle between the two takes place in every human heart.
Idiotul · Fiodor Dostoievski · 1869
Dostoevsky puts the claim in the mouth of a character considered naive, precisely so it will not sound like a slogan. The whole novel is the test of this thesis: beauty in the book is not only harmony but also seduction, vanity, the power to blind. The mechanism the author shows: what charms us also disarms us, because admiration lowers moral vigilance. An admired face can hide cruelty; an admired work can justify anything. That is why beauty is terrible: it demands a judgment that admiration alone cannot supply, and exactly there, between fascination and discernment, it is decided what beauty will do to us.
Beauty will save the world. Beauty is a mysterious and terrible thing; here God and the devil struggle with one another, and the battlefield is the heart of man.Idiotul, partea a II-a, cap. 5
Why it matters At a time when readers ask whether different outlets tell the same story and whom to believe, Dostoevsky shows that the charm of a formulation is not evidence — and that discernment is work, not impression.
In full →Collapse ↑
The card says admiration lowers moral vigilance. The next step: admiration does not only lower vigilance, it also hands us a ready-made excuse. When something is beautiful, we feel the judgment has already been made, so we stop checking. Dostoievski shows this through characters who forgive cruelty simply because it comes wrapped in a face or a talent that charms them. Think of a colleague who says ugly things, but with such good humor that everyone laughs and moves on. The laughter becomes permission. From here comes the practical question: how do you tell whether you are judging something, or merely blinded by its charm?
- 28
Man is split between the desire to live intensely here, in the body, and the aspiration toward something higher — and he can never settle for either one alone.
Faust. Prima parte a tragediei · Johann Wolfgang von Goethe · 1808
Goethe here formulates the conflict that will carry the whole tragedy: Faust is not a simple sinner but a divided consciousness that suffers from its own division. The mechanism is unresolved tension — the soul that clings to the world anchors him in experience, while the one that soars makes him restless with every earthly gain. That is why the pact with the devil looks like a solution: a promise to taste everything without ever having to choose. Goethe shows that the man who wants it all is not cunning, but desperate about his own dual nature.
Two souls, alas, dwell in my breast, and each would fain be parted from the other: one clings to the world with lusty love, gripping it with all its organs; the other rises forcibly from the gloom to the high fields of our forefathers.Faust I, versurile 1112–1117 (scena „Noaptea”, monologul lui Faust)
Why it matters Debates about artificial consciousness and asking clergy for advice reopen Faust's question: can something both desire and aspire at once?
In full →Collapse ↑
The card passage showed the split. The next step is different: Goethe does not treat division as a flaw to fix, but as the very engine of Faust's life. If either of the two souls won definitively, the man would stop moving. The one clinging to the world would grow lazy in pleasure; the soaring one would grow cold, mere contemplation. The tension is what keeps him alive and searching. Think of someone who loves their family and yet dreams at night of a completely different life. That is not betrayal, but the same double motion. The division hurts, yet it also produces the hunger that drives Faust toward the pact. The question that opens: what happens when someone tries to answer this tension with a single transaction?