First month at Brights — what an ISO 27001 ISMS function actually does day-to-day

I've been at Brights for a month as their first cybersec hire. The ISO 27001 ISMS work is way less bureaucracy and way more cross-team negotiation than I expected. Notes for future-junior-me.

I joined Brights as a Junior Cybersecurity Specialist in early September — their first dedicated cybersec hire after they got ISO/IEC 27001:2022 certified earlier in the year. I’d been here as a summer intern in 2024 doing OWASP Top 10 review on three internal apps, so this isn’t a green-fields onboarding. But the full-time cybersec role is its own distinct shape, and I want to write down what I’ve actually been doing this month before it starts feeling normal and I forget how new it all felt.

The thing I had wrong about ISMS work

I expected ISO 27001 ISMS work to be document-shuffling and policy maintenance. Bureaucracy. Update the risk register, file the audit-evidence folders, write a new policy when something breaks, repeat.

It’s not zero of that. But the actual day-to-day is much more cross-team negotiation — translating between what the standard requires, what the team’s existing practices actually do, and what’s realistic to change without breaking working processes.

A concrete example from this month: ISO 27001 Annex A.5.7 (Threat intelligence) says the org should “collect and analyse information relating to information security threats”. Brights had nothing formal in place — informal Slack channels where senior engineers occasionally shared CVE alerts, but no structured intake / triage / action loop.

The ISO-checkbox version of “fix this gap” would be: write a threat-intel policy, create a SharePoint page, declare done.

The actually-useful version is: figure out what threat intel a 50-person shop can realistically consume (we’re not staffing a 24/7 SOC team), how to triage it with junior-level effort (i.e. mine), what specific CVE/IOC subscriptions matter for our stack (Node, .NET, AWS, Azure, the specific OSS dependencies the dev teams use), and how to push something actionable to dev leads when something matters for our actual code.

The ISO checkbox is downstream of doing the practical thing. If you do the practical thing, the documentation writes itself. If you do the documentation thing first, you have a binder full of policies that nobody references. (Senior cybersec friends have been telling me this for years and I half-believed them. Now I believe them.)

The split

Roughly:

• ~30% SOC / detection / vuln management. Internal log review (we have Suricata on the dev/staging perimeter, ELK ingest pipelines I built up from the intern-summer Filebeat work), vulnerability scanning on internal/customer-facing assets, triaging CVE alerts against our dependency tree.
• ~30% ISMS / compliance / audit support. Risk register maintenance, gap-tracking against Annex A controls, prep for the external surveillance audit in November, vendor security-questionnaire review.
• ~25% AI risk / ISO 42001 readiness. Building a NIST AI RMF crosswalk against our existing 27001 controls, mapping which AI-risk controls Brights already implicitly handles via existing engineering practice and which need new process.
• ~15% awareness training / human stuff. Phishing-test rollout prep (we run them quarterly), responding to “is this email suspicious?” tickets from sales and customer-support team members.

The 25% on AI risk is what justifies the conference-travel sponsorship I got — Brights is positioning to add AI-services to their offering and the founders correctly identified that going from “27001 cert” to “42001 cert” requires real work, not just an additional binder. I’m the person doing that work, which is fortunate because it’s the most intellectually interesting part of the role.

Practical things I did this month

A few specific items that landed:

1. Migrated the Suricata + ELK lab from my BSc thesis docker-compose into the Brights staging environment, on a dedicated VLAN. The ruleset is ~30 thesis rules + ~10 Brights-specific (we have a few Node + .NET specific ones now). Filebeat ships eve.json into the Elastic cluster. Nothing fancy, working baseline.

2. Wrote a one-page “ISO 27001 control → engineering practice” crosswalk for the dev leads. Most engineering teams don’t have time to read the full standard. I read it, summarised the 93 Annex A controls into “what does this actually mean for someone writing Node code at a 50-person agency”, attached examples. Got useful feedback (“we already do this implicitly”, “we don’t do this at all”, “we do a worse version of this”) that’s now driving the gap-track.

3. Built a quarterly threat-intel digest template. Sources: CERT- UA bulletins (UA threat angle), CISA KEV catalog (urgent CVE), our AWS/Azure security advisories, npm/NuGet security advisories (matched to our actual dependency tree). Triaged outputs go to dev leads in a 1-page Friday email. First issue ships next Friday.

4. Started the ISO 42001 readiness gap analysis. This is going to take months. I’ve spent the September window reading the standard cover-to-cover, mapping the 38 controls, and starting the AI-RMF crosswalk. Not done. Probably won’t be done by Christmas.

What I’m still bad at

A short and humbling list:

• Saying “I don’t know” in cross-team meetings. I have an instinct to bluff because I’m the only cybersec person in the room. My manager has caught me doing it and pushed back gently — “if you’re not sure, say so and look it up later”. She’s right, I’m trying.
• Estimating effort. I told the founders the AI-42001 readiness work would take “two months”. Actual answer is “six to nine months, depending on how much engineering time we get from the AI-services team”. I underestimated by 3-4×.
• The audit narrative. ISO audits aren’t pass/fail tests; they’re guided tours where the auditor decides whether you understand your own ISMS well enough to be trusted to operate it. The November surveillance audit will be my first time presenting the ISMS to an external auditor and I’m noticeably nervous about it.

Small joys

• The team is genuinely interested in security as a topic, not just as a checkbox. The dev leads ask good questions in security reviews. The CTO has a personal home-lab CTF habit. The CEO read Schneier’s Liars and Outliers over the summer and references it. This is a much better starting point than I expected.
• Free coffee is unlimited.
• Hybrid setup (3 days in office, 2 remote) is genuinely the right pace for me right now.

I’ll write more as I have more to say. Probably the next post is either the November surveillance-audit retrospective, or whatever I take away from BSides SF in March.

(I picked Brights specifically because the cybersec function was nascent enough that I’d get to build parts of it, not just operate parts of it. That call has held up after one month — first-junior-hire roles trade ambiguity for ownership, and I’m getting both in appropriate doses.)

Слава Україні. 🇺🇦