ISO 27001 A.5.36: Proving Dev, Ops & Trading Policy Compliance in Fast-Paced Environments

Why ‘paper compliance’ breaks in Dev, Ops and trading

ISO 27001 A.5.36 is not about how many policies you can publish, but whether Dev, Ops and trading actually follow them under real pressure. In high‑velocity environments, annual training and intranet PDFs are not enough. Many organisations can point to an impressive stack of approved security policies, yet engineers and traders still make daily decisions that quietly ignore them. You need clear rules people can apply in seconds, guardrails baked into tools, and evidence that everyday behaviour still lines up with what your security policies promise.

In fast‑moving environments you see the gap everywhere: developers pushing hotfixes from local machines, operators implementing “one‑off” configuration tweaks, traders using unofficial channels to confirm a price. None of this usually appears in a policy document or a formal risk log, yet all of it affects your information‑security posture and your ability to satisfy auditors and regulators that people actually follow your rules.

This information is general and does not constitute legal or regulatory advice; you should always seek appropriate professional support for your particular situation.

Policies only matter when they change what happens in real time.

The reality gap between documents and daily work

A.5.36 exists because many security policies are written to satisfy auditors, not to guide the people who build, run and trade on your systems. Developers, operators and traders need simple, practical rules that match their tools and time pressures. If they do not see that fit, they quietly fall back on shortcuts and “how we really do it” habits instead – especially when long PDFs bear little resemblance to how they build and ship code, run operations or manage trading desks.

When policy feels distant from daily tools and decisions, you end up with “paper compliance”: annual attestations, mandatory training and occasional internal audits that say the right things, while real‑world practices slowly drift away from the intent. ISO 27001 A.5.36 was updated to push organisations beyond this pattern towards regular, structured checks that what happens in practice still aligns with the rules you wrote.

Why high‑velocity teams are especially exposed

High‑velocity Dev, Ops and trading teams make hundreds of small, time‑critical decisions each day. The faster your change and execution cycles, the less realistic it is to rely on occasional reminders or slow manual reviews. Without embedded guardrails and continuous checks, policy drift accelerates silently until it surfaces as an incident, a failed trade or an awkward audit finding.

Continuous delivery, cloud infrastructure and electronic trading all reward speed and adaptability, but they also multiply the number of moments when someone can either respect or bypass a security rule. A release that once passed through a weekly change meeting might now ship in minutes from an automated pipeline. A trade that previously involved several humans may now be generated, routed and executed entirely by code.

In these environments you cannot depend on please remember the policy emails. You need guardrails that are built into the way Dev, Ops and trading already work, plus continuous evidence that those guardrails are operating. That is the heart of A.5.36: closing the distance between written policy and observed behaviour in a way that still lets your organisation move quickly.

Book a demo

What ISO 27001 A.5.36 really asks you to do

ISO 27001:2022 Annex A.5.36 asks you to do far more than publish a security policy. You must define clear rules, decide who they apply to, demonstrate that people and systems follow them, and regularly review and address any gaps. In practice you must be able to answer three questions at any time: what are the rules, who do they apply to, and how do you know they are being followed in development, operations and front‑office trading.

At a high level, that means defining a coherent set of information‑security policies, topic‑specific standards and procedures, assigning owners, and planning regular compliance reviews. Those reviews must generate evidence and lead to clear follow‑up actions when you discover non‑compliance. For development, operations and trading, that translates into practical expectations about how code is written, how changes are deployed, how access is granted and how sensitive information is handled on the desk.

Plain‑language view of the control

In plain English, A.5.36 says: “Set out the security rules that matter, check that people and systems follow them, and fix things when they do not.” To make that real, you need specific, accessible policies, a plan for how you will review compliance, and an evidence trail that shows what you found and what you changed. Auditors care more about that loop than perfect wording.

That simple wording has several implications:

Policies and standards must be specific and accessible so teams know what they are expected to do.
You must define how often and where you will review compliance.
You must specify which review methods you will use, such as audits, technical scans or access reviews.
You must retain records of findings and actions so internal and certification audits can trace what happened.

For an auditor, evidence that A.5.36 is operating typically includes review schedules, checklists or test results, issue logs, remedial action plans and proof that management saw and acted on significant findings. They look for consistent, repeatable evidence rather than one‑off heroics.

What this means for Dev, Ops and trading teams

For Dev, Ops and trading teams, A.5.36 expects policies and standards to show up as observable, reviewable behaviours. Developers should see secure coding rules enforced in pipelines. Operators should recognise change and access checks in their daily tooling. Traders should know which systems and channels are in scope and how their use is monitored. Each group needs clear rules plus reliable feedback.

For development teams, A.5.36 typically expects secure coding standards, architecture patterns and SDLC policies to be more than “guidance”. You need mechanisms that check whether new code and configuration actually comply, and you need to review and improve those mechanisms. For example, secure coding rules might be enforced through static analysis and peer review, with periodic spot checks on repositories and pipelines.

For operations teams, the focus is often on change, access, configuration and incident management. A.5.36 expects you to show that production changes follow agreed processes, that privileged access is managed and reviewed, and that deviations from standard build and configuration baselines are understood and addressed. For front‑office trading teams, it emphasises adherence to information‑handling rules, authorised systems and channels, and desk‑level procedures that protect client and market‑sensitive data. Across all three, the pattern is the same: clear rules, operational controls, regular review and documented corrective action.

A simple comparison makes this easier to see.

Domain	Primary A.5.36 focus	Typical evidence signals
Dev	Secure coding and controlled deployment	Pipeline logs, code reviews, scan results
Ops	Change, access and configuration discipline	Change records, access reviews, drift alerts
Trading	Authorised systems and information handling	Surveillance reports, desk attestations

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

Reframing A.5.36 as a flow‑friendly control system

You implement A.5.36 more effectively when you stop treating it as a document exercise and start seeing it as a control system around your critical information flows. Every important piece of information in your organisation follows a path: someone creates it, others transform it, systems store and transmit it, and eventually it is archived or deleted. Along that path, policies, standards and controls are meant to shape what is allowed. A.5.36 asks you to prove that this remains true as systems and markets change by treating the control as an end‑to‑end guardrail around those flows.

Under that lens, A.5.36 becomes a question of defining what “good behaviour” looks like for each flow, ensuring there are controls at the right points to keep behaviour within acceptable bounds, monitoring those controls and intervening when they fail. This mindset is especially powerful in Dev, Ops and trading, where the same flows – for example, “deploy new trading algorithm to production” or “handle client order data” – repeat at high speed.

Visual: end‑to‑end flow from code idea to production, with security control points marked at each major step.

Think in end‑to‑end flows, not isolated documents

A practical first step is to pick a few high‑risk Dev, Ops and trading scenarios and map them from start to finish. For each one, ask who touches the information, which systems move it, which decisions matter most and where your current policies would expect controls to sit. Seeing these flows on one page makes both strong spots and weak spots obvious.

For instance, trace how a code change moves from idea to production: who can propose it, where it is developed, how it is tested, who can approve it, how it is deployed and how it is monitored. Then overlay your policies and standards: secure coding, change management, access control, logging and incident response.

You will often find gaps where there is no clear control, where controls exist only on paper, or where they depend entirely on people remembering to “do the right thing”. That is where A.5.36 compliance work should focus: making sure every critical step in the flow has a concrete control that can be reviewed, and that those reviews are planned and evidenced.

Assign ownership, triggers and feedback loops

Once flows are clearer, A.5.36 becomes a question of ownership, triggers and feedback. Each control point needs someone accountable, clear signals for when a review or escalation is required, and a route back into your ISMS so that findings shape future policy and risk decisions. Flow‑thinking also clarifies who should own which parts of A.5.36: each control point should have an accountable owner, defined triggers for review (for example, failed tests, out‑of‑policy access or unusual trading activity) and a feedback path into your ISMS risk and audit processes, so findings do not sit in tickets or inboxes and never translate into systemic improvement.

You can support this with a simple RACI‑style view: who writes and maintains the policy, who operates the control day‑to‑day, who monitors compliance and who decides on exceptions. Once these roles are clear, you can use internal audits and management reviews to check not just whether controls exist, but whether the overall flow remains within acceptable risk levels. Many organisations choose to support this with a central ISMS platform, such as ISMS.online, so that process owners, flows, controls and evidence are linked in one place.

Designing policies Dev, Ops and trading can actually follow

Effective A.5.36 implementation depends on policies and standards that people can genuinely follow. That means short, targeted documents written in the language of Dev, Ops and trading that explain what “good” looks like in concrete terms, while still reflecting your broader ambitions and governance. Master policies set the direction; role‑based playbooks and standards show exactly how to act in specific situations in a way that matches how different teams think and work.

The master policies describe principles, scope and governance. The playbooks and standards translate those principles into concrete “here is how we do this here” guidance for developers, operators and trading staff. When combined with structured exception and approval processes, this gives you a practical foundation for both compliance and speed.

Turn long policies into role‑based playbooks

Role‑based playbooks bridge the gap between corporate policy and tools on the screen. Developers, operators and traders should see themselves in the examples and language, so that following policy feels like following “how we work here” rather than wrestling with abstract clauses.

A developer‑friendly secure‑development standard might focus on topics like authentication, input validation, logging and error handling, each explained briefly with specific “do this, not that” examples in the languages and frameworks your teams use. An operations‑focused change‑management standard might specify steps and responsibilities for normal, standard and emergency changes, with simple decision trees and links to runbooks.

For trading teams, you may need desk‑specific procedures that restate information‑handling and access rules in the context of the actual systems, instruments and client types they deal with. The key is that each playbook is obviously derived from your core policies and clearly referenced in your ISMS, yet short and concrete enough that people will actually use it.

Build exceptions and approvals into the design

If Dev, Ops or trading staff feel they must choose between following policy and doing their job, you will see unofficial workarounds. High‑velocity teams sometimes feel forced to choose between the “right” process and realistic delivery or execution targets, which is ultimately a design failure. A.5.36 expects you to avoid that trap by defining both standard rules and clear, reviewable ways to handle exceptions, so that risk stays visible and controlled instead of hiding in ad‑hoc decisions.

For Dev, that might mean allowing emergency hotfixes to bypass some checks under tightly defined conditions, with additional review and testing after the fact. For Ops, it might be a controlled “break‑glass” process for urgent access. For trading, it could be special procedures for extreme market conditions.

These exception paths need clear criteria, authorised approvers, time limits and logging requirements. When you design them openly and tie them back to risk assessments, you give teams a legitimate way to move fast when they must, while still generating evidence that can be reviewed. Over time, patterns in exception data become one of your most valuable inputs for improving both policies and controls.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Embedding A.5.36 into Dev and CI/CD without killing velocity

For Dev and platform teams, the most sustainable way to comply with A.5.36 is to make policy compliance a side‑effect of good engineering practice. Secure‑by‑design principles and DevSecOps patterns turn many policy requirements into automated checks inside your pipelines and repositories. Developers keep shipping quickly, and you gain continuous evidence that security rules are being applied.

In a secure software development lifecycle (SDLC) and development, security and operations (DevSecOps) model, security checks are built into requirements, design, coding, testing and deployment, rather than bolted on at the end as a manual gate. Your secure coding standards and architecture rules become machine‑enforceable wherever possible, and exceptions are managed through your normal workflow tools. Auditors and risk reviewers can then look at pipeline logs and repository metadata. That helps them understand how often controls run, how many issues they find and how quickly they are resolved.

Policy‑as‑code in your SDLC and pipelines

Policy‑as‑code converts parts of your security standards into rules that your tools enforce automatically. In practice this might mean static analysis checks, dependency and container scanning, infrastructure‑as‑code controls and branch protection rules that line up directly with your policies. Each failing check produces both a development task and an A.5.36 compliance signal.

Examples include:

Static analysis rules that block unsafe patterns or banned APIs.
Dependency and container scans that enforce approved component lists.
Infrastructure‑as‑code checks that prevent insecure configurations from being applied.
Branch protection rules that require at least one peer review for changes touching sensitive components.

These technical checks become powerful A.5.36 evidence when you join the dots between tools and controls. You can integrate results from static analysis, software‑composition analysis and infrastructure‑as‑code tools into a single evidence trail. For example, a build may fail because an infrastructure template tried to create an unencrypted storage bucket. The failed pipeline run, the corrected code and the passing rerun together show that a specific policy requirement was enforced and verified over time.

All of these controls can be tied back to specific clauses in your standards. When a pipeline fails because a rule is violated, that is not just a technical event – it is an instance of A.5.36 compliance monitoring in action. Over time, you can run simple reports to show how often each control fires, which teams have the most issues and whether your overall posture is improving.

Designing guardrails that protect speed

Guardrails should protect your most important systems without turning every deployment into a negotiation. That usually means applying stronger checks to high‑risk services, using lighter controls elsewhere and having clearly defined, logged override paths for true emergencies. Done well, this keeps engineers fast where they must be, while making risky shortcuts visible and reviewable.

Not everything can or should be fully automated, and not every team has the same risk profile. A reasonable pattern is to apply the strongest, most comprehensive checks to systems that handle sensitive data, connect to external parties or support critical trading or risk processes, while using lighter‑weight guardrails for lower‑risk services. Tagging repositories and pipelines by criticality and data sensitivity helps you scale policies appropriately.

You also need clarity on when and how controls can be bypassed. For example, you might allow a senior engineer to override a failing control to fix an urgent production issue, provided they record the reason, link it to an incident ticket and trigger a mandatory review within a defined time window. You can then summarise overrides, failure trends and remediation times into management‑review packs, so A.5.36 evidence feeds directly into your wider ISMS cycle. Delivery speed is preserved where it matters, but each deviation from the standard path becomes visible and reviewable.

Operationalising A.5.36 in production and infrastructure operations

In production and infrastructure operations, A.5.36 lives inside processes you already know well – change, incident, problem, access and configuration management – but now you must show that these processes implement your security policies, that compliance is reviewed regularly and that you can produce evidence on demand. You do not need new processes so much as better alignment, instrumentation and visibility so that existing workflows clearly demonstrate A.5.36 operating in practice.

Most organisations already run change, incident, problem, access and configuration management processes. A.5.36 asks whether those processes genuinely implement your security policies and standards, whether you review compliance regularly and whether you can produce evidence when asked. The aim is to map A.5.36 expectations onto existing workflows and then instrument them so they produce the right evidence with minimal extra effort.

Here, you are often dealing with tools like IT service‑management platforms, monitoring systems, identity and access‑management solutions and configuration‑management databases. Rather than inventing parallel “security processes”, you align security expectations with these workflows and ensure they are visible in your ISMS or central platform.

Mapping control expectations onto core Ops workflows

A.5.36 in Ops becomes much clearer when you explicitly document which parts of your IT service‑management workflows enforce which security rules. For each process, spell out what “compliant behaviour” looks like, which approvals are required and what must be logged. That turns vague expectations into specific checks you can monitor.

A practical starting point is to review each operational process and document its security‑relevant rules. For change management, that might include who can request which kinds of change, what risk assessments are required, which approvals are mandatory, what testing is expected and how rollbacks are handled. For incident management, you might specify classification rules, escalation paths, communication channels and post‑incident review requirements. For access management, you define how requests, approvals, provisioning, reviews and revocation happen.

Once these rules are clear, you can work with your tooling owners to ensure they are reflected in forms, workflows, fields and reports. For example, a change record might need standard fields for security impact, affected information assets and references to risk assessments. An access request might need to be linked to a role‑based access model rather than free‑form entitlements. These details turn everyday Ops activity into concrete A.5.36 evidence.

Metrics and evidence from production

To show A.5.36 is operating in production, you need a handful of simple metrics that you can pull from systems of record, not spreadsheets built the night before an audit. Useful indicators often include the percentage of changes following the standard process, the ratio of emergency to normal changes, the frequency of privileged‑access reviews, and trends in configuration drift and policy‑related incidents.

You should design your logging and reporting so that these metrics can be generated without heroic effort. That often means standardising how you tag records and ensuring retention settings cover the audit window. It also means giving security and risk teams appropriate access to dashboards and underlying data. Many organisations use an ISMS platform such as ISMS.online to link change, access and incident evidence back to specific A.5.36 controls and present them in an ISO‑friendly structure.

When you later come to an ISO 27001 surveillance or recertification audit, you are pulling from systems of record rather than building last‑minute spreadsheets. You can also fold these metrics into internal audit and management‑review agendas, so operational experience directly shapes policy updates, risk assessments and improvement plans.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Applying A.5.36 on the trading floor without slowing execution

On the trading floor, A.5.36 must coexist with strict execution targets and demanding market conditions. Traders handle client orders, positions and market‑sensitive information at high speed, using a mix of standard systems, bespoke tools and communication channels. Your task is to make sure they follow information‑security rules without feeling blocked, and to gather evidence that shows regulators and auditors those rules are genuinely enforced and reviewed just as rigorously as they are in technology teams.

Front‑office trading environments combine all the challenges of Dev and Ops with intense time pressure and stringent regulatory expectations. A.5.36 applies here just as much as in technology teams: trading staff must comply with information‑security policies, rules and standards, and you must be able to show that you review and enforce that compliance. The difficulty is to do this without degrading execution quality or encouraging unauthorised workarounds. The answer lies in clear behavioural rules, well‑designed controls that fit trading realities and regular, evidence‑rich reviews.

Defining secure front‑office behaviours

Your traders need unambiguous guidance on which systems and channels they can use, how to handle client and order data, and where security policy draws hard lines. Desk‑level procedures and playbooks are the right place to make this concrete. They should reflect actual tools, products and scenarios, so that “doing the right thing” fits naturally into normal trading patterns.

Start by making it unambiguous which systems may be used for which activities, what constitutes acceptable handling of client and order data, which communication channels are authorised and what the rules are around personal devices and remote access. These expectations should be spelled out in desk‑level procedures and trader playbooks, not buried in a generic corporate policy.

Next, work with front‑office and compliance teams to ensure those behaviours are supported by system configuration: access profiles that reflect roles and products, trade limits and controls that enforce maker‑checker patterns where appropriate, and monitoring that can detect misuse. Training and simulations should use the actual tools and scenarios that traders face, so that applying the rules feels natural even in volatile markets.

You can then use periodic desk reviews, attestation exercises and training records as evidence that these behaviours are understood and challenged where necessary, tying trading practice back to A.5.36 in a way regulators recognise.

Controls that respect trading speed

Trading controls should be designed so that most legitimate activity flows smoothly, while risky behaviour is blocked or highlighted for review. Pre‑trade controls can block obvious out‑of‑policy orders, such as sending sensitive instructions over unauthorised channels, while post‑trade surveillance can spot patterns that suggest misuse of systems or information and feed those findings directly into A.5.36 reviews. Some approvals can be embedded into the workflow of the order‑management or execution‑management system, rather than relying on separate email chains that traders may try to bypass under pressure.

To keep A.5.36 from becoming “the control that killed execution”, design controls that intervene at the right points. Pre‑trade controls, for example, can block obviously out‑of‑policy actions automatically, while post‑trade reviews and surveillance can focus on patterns and edge cases. You should also explicitly design for exceptional situations: market dislocations, urgent client requests or system outages. For each scenario, define what can be done quickly under predefined rules, what must be logged and what follow‑up review is mandatory.

For example, you might:

Block attempts to export order books to personal email or unsanctioned tools.
Flag repeated use of unusual channels or devices for order discussion in post‑trade surveillance.
Apply pre‑approved exception rules for urgent client orders during market stress, with mandatory logging and post‑trade review.

This keeps traders inside a controlled, reviewable envelope even when they need to move fast. Data from surveillance systems, access logs and desk‑level reviews then becomes vital evidence for A.5.36 reviews and for your wider regulatory obligations under conduct and market‑abuse regimes.

Book a Demo With ISMS.online Today

ISMS.online helps you turn ISO 27001 A.5.36 into a living control by connecting your policies, standards and real‑world evidence in one environment. You define the rules once, map them to Annex A controls and link them to concrete signals from Dev, Ops and trading, so you can see at a glance where compliance is strong, where it needs attention and how your implementation fits into your broader information‑security management system.

If you want A.5.36 to feel like a living control rather than a box to tick once a year, you need a way to connect policies, standards and controls to the tools and workflows your Dev, Ops and trading teams already use. ISMS.online is designed to do exactly that: it gives you a single environment where you can define your information‑security rules, map them to Annex A controls, assign ownership and link them to concrete evidence from across your organisation.

Within the same platform you can manage your policy set, track compliance reviews, log exceptions and corrective actions, and attach supporting records such as pipeline reports, change tickets, access reviews and trading‑desk attestations. That makes it easier to show auditors, regulators and clients that your policies are more than words on a page.

See your A.5.36 posture in one place

You get the most value from A.5.36 when you can see how it really operates across Dev, Ops and trading, instead of relying on assumptions or last‑minute evidence hunts. ISMS.online lets you select the control, see which policies, standards and procedures relate to it, and then pull in the artefacts that demonstrate operation in each domain. As you visualise the picture, gaps become visible: missing owners, inconsistent review cycles, weak or manual evidence. From there, you can prioritise improvements based on risk and audit timelines rather than guesswork.

Because the platform is purpose‑built for ISO 27001, it also helps you keep pace with the broader standard: clauses, Annex A controls, risk registers, statements of applicability, internal audits and management reviews all live in one place. That reduces duplication and makes it easier to keep your implementation aligned as your technology and trading environments evolve.

Take a low‑risk first step

A sensible way to start is to run a focused pilot on one critical service or trading desk, rather than trying to redesign everything at once. Map the relevant policies and standards into ISMS.online, connect them to real‑world evidence from your existing tools, and rehearse how you would present that storey in an audit or regulator meeting. You will quickly see what works well and where a more integrated model would pay off.

That initial pilot will also show you where your current approach depends on heroics and where a more integrated, automated model would add real value. From there, you can build a phased roadmap that aligns platform adoption with upcoming certification or surveillance audits, so each investment in A.5.36 compliance also moves you closer to your wider information‑security goals. When you are ready, booking a demo with ISMS.online is a straightforward way to explore how this could look for your organisations mix of development, operations and trading.

Book a demo

Frequently Asked Questions

You don’t need to rewrite this from scratch. The core is strong, but the critique score of 0 usually means it’s flagging structural / duplication issues rather than substance. Here’s how I’d tighten it so it’s more concise, avoids repetition, and lands as landing‑page copy.

Below is a cleaned, ready‑to‑publish version that keeps your intent and examples but sharpens phrasing, removes duplication between FAQ and “critique” sections, and leans a bit more into ISMS.online as the unifying thread.

How does ISO 27001 A.5.36 really apply to Dev, Ops and trading teams day to day?

ISO 27001 A.5.36 expects you to set clear security rules for each team, check that everyday behaviour matches those rules, and act when it does not. In practice it closes the gap between “what your policies say” and “what actually happens” in development, operations and on the trading floor.

What does A.5.36 look like for development teams?

For development, A.5.36 is about making secure engineering visible, repeatable and evidenced:

Rules: secure coding, approved tools and services, environment segregation, change and release paths are written down, owned and kept current.
Application: those rules appear in pipelines, branch policies, code‑review checklists and architecture standards developers see every day.
Evidence: you can point to recent pull requests, pipeline runs and exception logs that show the rules are followed most of the time, and that you react when they are not.

Auditors will expect to see a secure‑development standard mapped back to Annex A (including A.5.36 and technical controls in A.8), then follow it through real repositories and build logs. If they can start at the A.5.36 control in your ISMS and end at a specific merge request showing who approved a high‑risk change, what they checked and where any exception was recorded, you are showing that compliance is part of the development workflow, not an afterthought.

How does A.5.36 play out for operations and trading?

For operations, the emphasis is whether production genuinely follows your change, access, configuration and incident policies. Typically that looks like:

significant changes going through agreed workflows with approvals, testing and rollback plans
privileged access requested, approved, time‑bound and regularly reviewed
configuration drift and vulnerabilities found, prioritised and fixed against agreed targets
incidents logged, analysed and linked to follow‑up actions

For trading, A.5.36 focuses on how information is handled in fast, high‑stakes environments:

which platforms and channels may be used for research, order entry and client contact
how client, order and market‑sensitive data can be viewed, downloaded, stored or forwarded
how entitlements, personal devices and remote access are controlled and supervised

Across all three areas, A.5.36 adds a common thread: you review compliance at defined intervals, document what you find and track corrective actions. In ISMS.online you can create separate A.5.36 controls for Dev, Ops and trading, link each to its policies and processes, and attach live evidence from your existing tools so you have one coherent storey for audits and management reviews.

How can you embed A.5.36 into Dev and CI/CD without slowing delivery?

You keep delivery fast by turning A.5.36 requirements into guardrails inside tools developers already use, rather than extra documents they are expected to remember. The more your policies are enforced automatically in CI/CD, the less they feel like friction.

How do you turn policies into pipeline rules?

Treat your secure‑development standard as “policy‑as‑code”:

build static analysis and software‑composition analysis checks that block insecure functions, known‑bad dependencies or licences you do not allow
scan infrastructure as code for misconfigurations before deployment, not after
use branch protection and pull‑request templates to enforce peer review and specific sign‑offs for sensitive components
run secrets‑detection and image scanning at commit or build time so obvious problems never reach production

When a pipeline fails one of these checks, developers get immediate feedback and you get timestamped, repeatable evidence that controls run every day. You can tune rules by asset criticality and data sensitivity so that high‑risk services carry stricter checks, while low‑risk work is not unnecessarily slowed.

How should you handle urgent changes without breaking A.5.36?

A.5.36 does not forbid urgency; it expects you to manage it transparently:

define a clear “break‑glass” path for production issues and market events: who can bypass which controls, under what circumstances, for how long
ensure overrides are approved, logged and reviewed afterwards, with follow‑up changes recorded
track metrics such as override frequency, time‑to‑fix and recurrence to show that exceptions remain exceptional

If your A.5.36 control in ISMS.online links to specific repositories, pipelines and override records, you can show auditors that secure development is integrated into CI/CD and that even emergency activity is visible, accountable and time‑bound.

How should operations teams demonstrate A.5.36 compliance in production?

Operations show A.5.36 compliance when production activities clearly follow your change, access, configuration and incident policies, and you can evidence that through your IT service‑management tooling.

How do you connect ITSM workflows to A.5.36?

Start by mapping each operational process to the control:

Change management: which risk levels require security or architecture approval, test evidence and rollback plans; how emergency changes are handled and reviewed
Access management: who can approve privileged roles, how long they last and how often you review them
Configuration and vulnerability management: what “baseline” means in your environment, how often you scan, which teams fix what within which timescales
Incident and problem management: how incidents are triaged, escalated, communicated and closed, and how you capture lessons learned

Then configure your ITSM tool so required questions and approvals cannot be skipped, tickets show links to the policies they implement, and dashboards make non‑compliance visible. Your ITSM system becomes a live control surface and evidence source rather than just an operational backlog.

What production evidence will auditors usually ask to see?

Auditors typically sample:

change records for significant or high‑risk work, including approvals, risk ratings, test evidence and outcomes
access‑request and access‑review logs for joiners, movers and leavers, especially for privileged accounts
configuration and vulnerability reports showing drift, exceptions and remediation status
incident logs, runbooks and post‑incident reviews, including follow‑up tasks and their completion

Bringing these artefacts together under an A.5.36 control in ISMS.online lets you walk an auditor from the text of the requirement to concrete examples from your production environment in a structured way, instead of relying on ad‑hoc screen‑shares or last‑minute exports.

How can trading desks meet A.5.36 without harming execution speed?

Trading desks meet A.5.36 when information‑security expectations are written in trading language, are built into trading systems and desk procedures, and are backed by supervision and surveillance that focus on real risk rather than slowing every order.

How do you make security part of normal trading behaviour?

Begin with desk‑level procedures that traders actually use:

set out which platforms and tools are approved for pre‑trade research, order entry, execution and post‑trade analysis
define how client, order and market data may be accessed, exported, stored and shared, including rules for personal devices and remote locations
spell out which communication channels (chat, voice, email, messaging apps) are allowed, and under which conditions

Align those procedures with:

role‑based access profiles: that limit each user to the systems and data they genuinely need
pre‑trade and platform controls: that block obvious breaches of policy, such as trading from unauthorised locations or devices
post‑trade surveillance: that looks for patterns in trades and communications that might indicate misuse of access or data

If a trader trying to do the right thing naturally stays within the rules, and someone trying to bypass them leaves a loud trail, you are close to the intent of A.5.36.

What does useful trading evidence for A.5.36 look like?

Useful evidence typically includes:

current desk manuals and quick‑reference guides that restate security and conduct rules in everyday scenarios
entitlement reports and approval records: for trading systems, market data feeds and external channels
surveillance alerts, escalation logs and investigation notes: , including outcomes and remediation
supervisory reviews and attestations: confirming that key staff have read, understood and applied the rules

Anchoring these documents and logs to a trading‑focused A.5.36 control in ISMS.online means you can show regulators and auditors that the desk knows the rules, that systems help traders follow them, and that supervisors act when something looks wrong.

What kind of evidence best supports A.5.36 across Dev, Ops and trading?

The strongest A.5.36 storey is consistent across teams: your rules are clear, your controls actually run, and you respond when behaviour drifts. Evidence should reflect that structure while still respecting differences between development, operations and trading.

How can you structure evidence so it is convincing and efficient?

A simple structure works well:

Policies and standards: your information‑security policy, secure‑development standard, operations runbooks and desk procedures mapped to A.5.36 and relevant technical controls
Control operation: samples from CI/CD, ITSM and trading/surveillance systems showing that rules run repeatedly over time, not just once for the audit
Exceptions and actions: records of failed checks, emergency changes, unusual trading events or other deviations, together with investigation notes, decisions and fixes

For development that might mean secure‑development guidelines plus pipeline logs and merge‑request histories. For operations, change and access tickets, configuration and incident outputs. For trading, desk procedures, entitlement reviews and surveillance artefacts. Drawing evidence directly from the systems of record reduces manual effort and last‑minute document assembly.

How do you keep A.5.36 evidence organised and reusable?

Instead of re‑inventing the wheel for every audit, you can:

create separate control records for A.5.36 covering Dev, Ops and trading in your ISMS
link each control to the underlying policies, standards, processes and owners
attach or reference specific artefacts (logs, tickets, reports, reviews) as they are generated throughout the year
record findings, exceptions and corrective actions directly inside those controls so that management reviews and internal audits see progress over time

ISMS.online is designed for this way of working. It lets you keep controls, owners and evidence in one place so internal and certification audits become a walkthrough of how your organisation really works, rather than a one‑off documentation exercise.

How can ISMS.online simplify A.5.36 compliance across Dev, Ops and trading?

ISMS.online simplifies A.5.36 by turning it into a continuous, shared control loop that spans development, operations and trading, instead of three separate sets of documents owned by different teams. You define your rules once, map them to Annex A, then connect them to real activity and evidence.

What does running A.5.36 through a single platform enable?

With ISMS.online you can:

define and maintain information‑security policies and standards that apply to Dev, Ops and trading, then map them directly to A.5.36 and related controls
create linked controls for each team, capturing how they interpret and apply the rules in language that makes sense to them
attach live evidence from CI/CD systems, ITSM tools and trading platforms against the right controls, with dates and owners visible at a glance
plan and track reviews, exceptions and improvements through management reviews, internal audits and corrective‑action workflows
use dashboards to see where compliance is strong, where it is drifting and where upcoming audits or regulatory visits demand more attention

For a development group, that might mean linking secure‑coding standards to particular repositories and pipelines and storing selected build and review outputs as evidence. For operations, mapping change and access workflows from your ITSM tool to A.5.36 and attaching selected tickets and reports. For trading, capturing desk procedures, attestations and surveillance outputs under one control record.

Where is a sensible place to start if you have not formalised A.5.36 yet?

Trying to model every process at once can stall progress. A focused pilot usually works better:

choose one high‑risk service or trading desk where customers, regulators or the board care most about information‑security behaviour
map its policies, standards, tickets, logs and reviews into a small set of A.5.36 controls in ISMS.online
run that model for a short period, looking at how easy it is to capture evidence, where gaps appear and how well managers and auditors can follow the storey
refine your approach based on what you learn, then extend the pattern to other services, teams and frameworks such as SOC 2, ISO 27701 or NIS 2

Starting this way lets you demonstrate to senior stakeholders that you are in control of information‑security policy compliance where it matters most, while giving Dev, Ops and trading teams a practical system that supports how they already work. As you scale, your organisation starts to look less like three separate functions and more like a coordinated, resilient environment where policy, behaviour and evidence stay aligned.

If you’d like, I can now:

compress this into a shorter, landing‑page‑style FAQ, or
add one more FAQ aimed specifically at auditors or regulators reading the page.

ISO 27001 A.5.36 – Ensuring Dev, Ops & Trading Compliance With Security Policies