Skip to content

Security and Compliance Project Management: ISMS, Audit Readiness and In-House AI Systems

Several years as project manager for a company's security and compliance work: ISMS and risk process, IAM including machine identities, incident response, audit readiness, awareness and protection of in-house AI systems.

Security and Compliance Project Management: ISMS, Audit Readiness and In-House AI Systems

The company had to run its IT, its cloud services and its own AI systems securely. At the same time it had to show that it met the requirements that applied to it from NIS2, TISAX, the ISO 2700x family, GDPR, KRITIS and sector-specific rules. That work touched strategy, identity, incident response, awareness and audit evidence all at once. We acted as project manager for that work over several years and ran it as one programme with named workstreams, a single decision route and one evidence trail.

The aim was a common path for management, the technical teams and the business: from a requirement or a threat report to an approved measure, and from that measure to a piece of audit evidence. The other aim was balance. Security had to protect the business without stalling modern, agile ways of working.

Starting point

The requirements came from several directions. Applications ran in the cloud. Automation and integrations needed their own credentials. The company operated its own AI systems. On top of that came regulatory and industry obligations that had to be met and evidenced: which systems exist, which risks they carry, who or what has access to them, and how the company responds to an incident.

Run as separate projects, the same questions get answered several times and evidence is gathered in a rush before each audit. We ran the work as one programme instead: shared workstreams, named owners, one place where decisions and evidence were recorded.

What we set up

The programme covered these workstreams, each with a named owner:

  • security strategy and policies, translated into concrete requirements for systems and processes;
  • the ISMS, with roles, a risk register and documentation that reflects the current state;
  • cyber, IT and cloud security, including threat analysis with the established SOC;
  • risk management and cyber intelligence;
  • identity and access management, including machine identities and Zero Trust;
  • compliance and audit preparation;
  • incident response for detection, containment and recovery;
  • awareness and training;
  • protection of in-house AI systems and handling of shadow IT.

Around these workstreams we set up the project management that held them together: a plan with milestones, visible dependencies, status reporting that management could act on, and an escalation route for decisions that stalled. Evidence was tracked as a deliverable in its own right, not reconstructed at the end.

Project management sat between the groups involved. Management decided on investments and residual risks. Technical teams implemented controls. The established SOC supplied threat analysis. Authorities, industry bodies and service providers were the outside contacts. Our job was to sequence the work, keep owners and dates visible, and translate between technical teams and management.

How the programme ran

Every security case went through the same sequence, whichever workstream it came from:

  1. Capture the requirement: a new regulatory obligation, a SOC finding, a new AI initiative or a vulnerability found in operations.
  2. Assess the risk: affected systems and data, likelihood, impact on operations, existing controls.
  3. Decide: a recommendation with residual risk, effort, an owner and a date, written so that management could decide without security jargon.
  4. Deliver: a policy, a technical control, an access restriction or a process change, tracked as a work item with an owner.
  5. Record the evidence: decision, implementation and effectiveness, in a form fit for an audit.
  6. Follow up: check effectiveness, update the risk register, adjust the plan.

The project management work was keeping that sequence moving across all workstreams at once. We ordered dependent tasks, surfaced clashing deadlines, escalated stalled decisions and reported progress in business language rather than as a list of technical activities.

Tailor your workshop with CypherX

ISMS, risk work and the SOC

The ISMS was the working basis: an inventory of systems and data, a risk register with assessments and measures, roles and responsibilities, operational policies, and a process to keep all of it current. Its structure followed ISO/IEC 27001, the standard for information security management systems (ISO/IEC 27001:2022). What mattered was the order it gave the work: every control traced back to a risk, and every risk had an owner.

We drove the build-up and upkeep of the ISMS as a workstream of its own, from the first inventory through the risk assessments to the policies used in operations. Cyber intelligence was not a separate data collection; it fed the same risk process. The established SOC delivered threat analyses and attack patterns. We set up the hand-over from the SOC into the programme, prioritised what was relevant to the company's own systems, and made sure each item became a task with an owner and a date. Risks were ranked by impact on operations, not by the volume of an alert.

Identities and Zero Trust, including machines

Access rights are where technical security and daily work meet most directly. We ran identity and access management as its own workstream: roles and permissions, granting and revoking access, reviewing existing rights, logging access.

Machine identities were part of the same scope. Service accounts, API keys, pipeline credentials and connections between cloud services are not people, but they need the same discipline: a named owner, limited rights, regular rotation and a clear way to remove them. Left alone, such accounts can stay valid and unnoticed for years.

The guiding principle was Zero Trust as NIST describes it in SP 800-207: trust does not follow from network location but from evaluating each request against identity, device and context (NIST SP 800-207). We used it to set priorities for the technical teams: who or what actually needs access, with which rights, and how that is checked.

Incident response: detect, contain, recover

We drove the definition of incident response processes and led them: detection and classification, roles and escalation paths, technical containment, communication inside and outside the company, recovery of operations, and a review with concrete changes. Lessons from each review went back into the ISMS, the risk register and the awareness work.

The key was separating responsibility from urgency. Who decides during an incident, who intervenes technically, who speaks to outside parties and who documents afterwards was agreed and written down in advance. Nobody had to negotiate roles when it mattered.

Compliance and audit readiness

Requirements from several frameworks overlap and sometimes conflict. We therefore kept a requirements catalogue that mapped each obligation to a control and a piece of evidence. It covered NIS2, the European cybersecurity directive with its risk management and reporting duties (Directive (EU) 2022/2555); TISAX, the assessment and exchange scheme for information security in supply chains (TISAX); GDPR for personal data (GDPR); KRITIS duties for critical infrastructure (BSI: KRITIS); and sector-specific rules where they applied.

Audit preparation was an ongoing part of the work, not a year-end project. We made sure evidence came out of daily operations: decisions with their reasoning, controls with dates, reviewed access rights and training records. Preparing for an audit then meant checking the files for completeness.

Protecting in-house AI systems and shadow IT

The company's own AI systems needed their own rules. The best-known risk is prompt injection: inputs that change a model's behaviour in unintended ways, including hidden instructions in third-party content (OWASP LLM01: Prompt Injection). Next to it stand data leakage through prompts, responses and logs, and tools that departments adopt without involving IT.

We turned these risks into review rules: which data may go into a model, which rights an AI system receives, what is logged, who approves a tool and how it is switched off again. New AI initiatives went through the same sequence as any other requirement: risk assessment, decision, evidence. That left room to experiment without uncontrolled data flows.

Management, awareness and external partners

Security work rarely fails on technology; it fails on decisions. For management we translated risk into business terms: what an outage means for operations and customers, which residual risk remains after a control, and what a given investment changes. That gave management a basis to decide on security questions themselves.

Awareness was the second lever. We drove the development of training programmes and promoted a security culture, backed by clear rules for access and data. We also coordinated the work with authorities, industry bodies and service providers, and brought providers' access and obligations into the same programme.

Balancing security and agility was a constant task. Not every requirement was answered with a ban. Often the better answer was a targeted control that let the business process continue. Keeping that trade-off visible in plans and decisions was part of the job.

Outcome

Over several years we delivered a programme that ran inside the company's own organisation:

  • a security strategy and policies applied in day-to-day operations;
  • a maintained ISMS with a risk register, defined roles and documented decisions;
  • identity and access management covering people and machine identities;
  • incident response processes with defined roles and escalation paths;
  • a requirements catalogue with evidence for audit preparation;
  • training programmes and rules for in-house AI systems and shadow IT;
  • a workstream plan with named owners and an evidence trail that management could follow.

Security work became part of normal workflows. Requirements became actions, actions became evidence, and responsibility stayed with the people who run the systems.

Sources