Security standards: ISO 27001, SOC 2

ISO/IEC 27001 is the international standard for running an information security management system. That is a repeatable way for an organisation to decide which security risks matter, treat them and keep improving. It does not prescribe one set of tools. Instead it requires you to understand your context and obligations, have management commit and assign responsibilities, assess risks, choose controls to treat them, operate those controls, measure how they work, run internal audits and management reviews, and correct what falls short. Its annex lists reference controls, from policies and supplier management to logging, monitoring and network security, and you explain which you apply. An organisation can have an accredited certification body audit it and issue a certificate, which is what customers usually ask for. Certification covers a defined scope, so always check which sites, services and teams the certificate actually includes. For a mid-sized company it is a serious project, mostly about people and process rather than technology.

It is the set of policies, roles, processes and records through which an organisation manages information security on purpose rather than by accident. An information security management system (ISMS) answers a few questions continuously: what information and systems matter, which risks threaten them, which measures we take, who is responsible, how we know the measures work, and how we improve when they do not. Concretely it consists of documents such as a security policy, a risk assessment and a risk treatment plan, a statement of which controls apply, procedures for incidents and suppliers, plus evidence that they are followed: training records, access reviews, audit results and management review minutes. It is called a system because it runs in a cycle of plan, do, check and act. ISO/IEC 27001 defines its requirements, but even companies that never seek certification benefit from the structure, and NIS2 risk-management duties fit naturally into one. A monitoring tool is one control inside the system and a source of its evidence; it is not the system itself.

It is the document that lists every reference control from the standard’s annex and says, for each one, whether you apply it, why, and how it is implemented. The statement of applicability (SoA) connects your risk assessment to your controls: a control is included because it treats an identified risk or meets a legal or contractual obligation, and excluded only with a stated reason, for example because you have no physical premises of your own. Auditors use it as a map of your ISMS and test the controls it claims; customers sometimes ask for it to understand what your certificate actually covers. Keep it short and factual, name the evidence for each implemented control, and update it when your risks or set-up change. A good SoA entry for monitoring names the tool, the systems it covers, who reviews its output and where the records are kept. If NetSenX is part of your monitoring, its network map, alert history and audit log can be referenced as evidence; the SoA itself is your document.

SOC 2 is an attestation report in which an independent auditor examines a service organisation’s controls against the Trust Services Criteria. The AICPA, the US accounting profession’s standards body, defines it. Security is always in scope; availability, processing integrity, confidentiality and privacy can be added. The report describes the system, the controls the company claims, the auditor’s tests and any exceptions found, and it is normally shared with customers under a non-disclosure agreement. Customers, especially in North America, ask for it because it lets them rely on an independent review instead of auditing each supplier themselves. It is not a certification and there is no pass mark: you read the auditor’s opinion, the scope and the exceptions. When a supplier sends you one, check the period covered, which services and locations are in scope, which criteria were included, and the complementary controls you are expected to run on your side. NetSenX does not hold a SOC 2 report today; SOC 2 Type I is in preparation.

A Type 1 report looks at whether controls are suitably designed and in place at one point in time; a Type 2 report also tests whether they operated effectively over a period, typically several months. Type 1 answers “do you have the right controls on this date?”; Type 2 answers “did they actually work throughout?”, which is why customers who rely on a supplier usually prefer it. A Type 2 needs evidence collected across the whole period: access reviews done on schedule, changes approved before release, incidents handled as the procedure says, monitoring alerts reviewed. A company often starts with Type 1 to fix its design, then runs the controls and collects evidence for a Type 2. When you read either, check the dates, the scope, the criteria covered and every exception the auditor lists, and ask how the exceptions were fixed. NetSenX’s own status is stated plainly: SOC 2 Type I is in preparation, no SOC 2 report of either type has been issued, and Type II would follow once controls have run over a period.

It depends mostly on who your customers are and what they ask for. ISO/IEC 27001 is an international certification of your management system, widely recognised in Europe and in public procurement; SOC 2 is an attestation report built on American auditing standards, common in North American software sales. Many European mid-sized companies are asked for ISO 27001 first, while companies selling software into the United States meet SOC 2 questionnaires. Both look at much the same controls, so the underlying work overlaps a great deal: risk assessment, access control, change management, supplier management, incident response, logging and monitoring. If you need both eventually, build one set of controls and map it to each framework rather than running two programmes. Before you start either, ask your largest customers and prospects which they accept, check whether a completed security questionnaire would do for now, and define the scope narrowly enough to finish. Neither replaces NIS2 duties. NetSenX holds neither today: SOC 2 Type I and ISO/IEC 42001 are in preparation.

ISO/IEC 42001 is the international standard for an AI management system: the policies, roles, risk assessments and controls through which an organisation develops, provides or uses AI responsibly. It follows the same management-system structure as ISO/IEC 27001, so companies that already run an ISMS will recognise the cycle of context, leadership, planning, operation, evaluation and improvement. What is specific to AI is the content: assessing the impact of AI systems on people and society, managing data used for training and testing, documenting systems over their life cycle, defining human oversight, and handling third-party AI components. An accredited certification body can audit it and issue a certificate. It is not the EU AI Act, and holding it does not by itself show that you meet the Act’s requirements, but much of the governance work it demands supports them. For a company that only uses AI tools, a full AI management system may be more than needed; an inventory, a usage policy and staff training are a sensible start. NetSenX is preparing for ISO/IEC 42001; it has not been awarded.

IEC 62443 is a series of international standards for the security of industrial automation and control systems, the operational technology (OT) that runs machines, plants and building systems. It divides responsibilities between asset owners who operate the systems, integrators who build them into a site and product suppliers who make the components, and gives each its own requirements. Central ideas are dividing the plant network into zones with controlled connections between them, called conduits; setting target security levels for each zone according to the threat; and maintaining security over the whole life cycle, from design to decommissioning. You need it if customers, insurers or regulators in your sector ask for it, or if you build or supply industrial components; many operators also use it as a structure for their own OT security without seeking certification. Network monitoring fits its emphasis on knowing what talks to what across zones. From the Pro plan, NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm passively and never probes OT devices; it is not a safety system and does not act on the process.

Not automatically, although it covers much of the ground. ISO/IEC 27001 gives you a risk-based management system and controls that overlap strongly with the cybersecurity risk-management measures NIS2 requires, such as incident handling, business continuity, supply-chain security, access control and cryptography. But NIS2 is law and the certificate is a voluntary standard, and they differ in places. NIS2 has its own staged incident reporting under Article 23 to a national authority, specific duties for management bodies including training and accountability, registration with the authority, and national rules that can go further. A certificate also covers only its stated scope, which may leave out the very services NIS2 applies to. Use your ISMS as the backbone: map each NIS2 measure to your controls, close the gaps such as the reporting procedure and management training, and make sure the scope includes every in-scope service. Check your national NIS2 law and whether it refers to standards. NetSenX tracks NIS2 reporting deadlines per incident; it does not assess your certificate or your NIS2 status.

Mainly the controls on logging and monitoring activities, and the network security and incident management controls around them. In the 2022 edition of the annex, logging (8.15) asks you to produce, protect and analyse records of activity, and monitoring activities (8.16) asks you to monitor networks, systems and applications for anomalous behaviour and act on it. Network detection evidences both directly. It also supports networks security (8.20), by showing which devices talk across segments, and the incident management controls, by giving a dated starting point for assessing and responding to events and collecting evidence. Asset inventory benefits too, since a network map shows devices that are not in your list. Monitoring does not cover access rights, backups, secure development or supplier contracts, so do not stretch the mapping. In your statement of applicability, name the tool, the segments it covers, who reviews alerts and where records are kept. NetSenX’s network map, alert history and audit log, on every plan, and its PDF compliance reports, from the Starter plan, can serve as that evidence.

Not today, and we say so plainly. NetSenX holds no ISO/IEC 27001 certificate and no SOC 2 report. SOC 2 Type I and ISO/IEC 42001 are in preparation, which means the work is under way and nothing has been awarded; we will update this page when an independent body issues something you can verify. What you can check now: the data processing agreement published on the website, with its list of sub-processors and their locations; where customer data is stored, with the database in Ireland and the API in Frankfurt and Paris; the security page; and our responsible disclosure policy for reporting vulnerabilities. We answer security questionnaires, and if your procurement requires a certificate we cannot yet provide, tell us early so you can decide with full information rather than discover it late. Some of our sub-processors hold their own certifications, which the data processing agreement lists; those cover their services, not NetSenX. If a supplier ever claims a certificate, ask for the certificate itself, its scope and the issuing body, and check it with that body.

It is a free framework from the US National Institute of Standards and Technology (NIST) that describes the cybersecurity outcomes an organisation should aim for. The outcomes are organised into the functions Govern, Identify, Protect, Detect, Respond and Recover. Version 2.0 added Govern, which covers strategy, roles, policy, risk management and supply-chain risk, and widened the framework from critical infrastructure to organisations of every size and sector. It is not a certification and does not prescribe tools; you describe your current profile, decide a target profile and plan how to close the gap, with implementation tiers describing how mature your approach is. European companies use it as a clear structure even though it is not EU law, often alongside ISO/IEC 27001 and NIS2, to which it maps well. Network detection belongs mainly under Detect, through continuous monitoring and analysis of adverse events, and supports Respond with information about what happened. NetSenX covers part of Detect on the segments it watches: beaconing, scanning, lateral movement and unusual outbound volume, on every plan. Govern, Protect and Recover need other measures.

IT-Grundschutz is the security methodology of Germany’s Federal Office for Information Security (BSI), widely used by German public bodies and companies. It consists of BSI standards that describe how to build an information security management system, carry out a protection-needs assessment and handle risks, plus a compendium of modules with concrete requirements for typical components such as servers, networks, applications, buildings and processes. Instead of starting every risk assessment from scratch, you model your environment with the relevant modules and apply their requirements, analysing risks separately only where protection needs are high or no module fits. An ISO 27001 certificate on the basis of IT-Grundschutz can be issued through the BSI, which combines both approaches. It is detailed and can be heavy for a small company, but its modules are a free, practical checklist even if you never seek certification, and they help with German NIS2 duties under the BSIG. Its network modules include logging and detection requirements that network monitoring helps evidence. NetSenX does not assess Grundschutz conformity.

A certification is an accredited body’s decision that you meet a standard, documented in a certificate. An attestation report is an auditor’s opinion on your controls, with the details of what was tested. ISO/IEC 27001 works by certification: an accredited certification body audits your management system, issues a certificate for a stated scope, and keeps checking with surveillance audits until recertification. SOC 2 works by attestation: an independent auditor tests your controls against criteria and writes a report with its opinion and any exceptions, which you share under a non-disclosure agreement. In practice, a certificate is easy to verify and compare but says little about detail; a report says much more but must be read, including its scope, period, exceptions and the controls you must run yourself. Both are only as useful as their scope is relevant to the service you buy. Be wary of vendors who describe a self-assessment, a policy or a consultant’s readiness review as either. NetSenX holds neither today; SOC 2 Type I and ISO/IEC 42001 are in preparation.

Start with scope and evidence, not with documents for their own sake. First fix the scope: which organisation, sites, services and systems the certificate will cover, chosen so that it matters to customers and can be finished. Then do the core work the standard requires: a risk assessment and treatment plan, a statement of applicability, the mandatory policies and procedures, assigned roles, staff awareness, and controls that actually run. Let them run long enough to produce records, such as access reviews, change approvals, incident tickets, supplier checks and monitoring reviews, because auditors test evidence of operation, not intentions. Run an internal audit and a management review before the external audit, and fix what they find. Certification audits are usually done in two stages: first a review of your documentation and readiness, then an assessment of whether the system works in practice. Choose an accredited certification body, and keep the consultant who helps you separate from the auditor. For the monitoring controls, NetSenX’s network map, alert history, audit log and PDF compliance reports can be part of your evidence; NetSenX does not audit or certify anything.