Gamma Architects Case Study: Phishing, OSINT & Architectural Practice Risk

Cyber Risk in Architectural Practice

Supporting secure decision-making across cloud systems, remote access, and collaborative project work.

The context

Gamma Architects is a small architectural practice working between Gibraltar and a mix of remote locations. Day-to-day activity moves across home and office environments, with staff regularly accessing company systems through Microsoft 365, cloud storage, and remote connections. Project documentation, communication, and collaboration are handled through email, Teams, and shared files, while archived material is stored on a network attached storage system that can be accessed remotely through a VPN when historic documentation is needed.

In practice, the work depends on speed, coordination, and trust. A request comes through asking for access to a set of drawings or project files. The sender is familiar. The request fits the stage of the project. Sharing the information quickly helps keep work moving and supports the wider rhythm of collaboration between colleagues, clients, and external partners.

Nothing about the moment feels obviously wrong. The request aligns with what is already happening, and responding quickly feels like part of doing the job properly. In that moment, the decision is not experienced as a cybersecurity decision. It is whether to keep the project moving or pause and question something that appears entirely legitimate.

That is what made the situation important. The pressure was not dramatic or explicit. It came from timelines, collaboration expectations, and the need to respond efficiently across multiple stakeholders. From a technical perspective, the practice had already taken sensible steps. Company laptops were managed by an external IT provider responsible for updates, antivirus protection, and general system maintenance. But the leadership team recognised that, in a modern professional environment, technical controls do not remove the need for judgement. Cybersecurity still sits inside the ordinary decisions people make while trying to get their work done.

The challenge

In architectural practice, communication is constant and often time-sensitive. Drawings are shared, documentation is reviewed, project updates move between teams, and financial or administrative requests sit alongside design work. Most of these interactions feel routine because they are routine. They arrive in the middle of active projects, from people already involved in the work, and in forms the team sees every day.

Because of that, risk rarely appears as something obvious. It sits within normal project communication, especially when requests are familiar, expected, and clearly connected to ongoing work. There is often no clear reason to question what is in front of you. The sender appears legitimate. The request fits the context. Acting quickly helps maintain momentum. Under those conditions, pausing can feel unnecessary, or even slightly disruptive.

The challenge was made more complex by the way the practice worked. Staff regularly accessed systems through personal devices while working remotely or moving between locations. That flexibility supported the business, but it also meant decisions were sometimes made in more isolated conditions, without the same opportunity to sense-check something with a colleague or verify it in the flow of shared office conversation. A message could be opened on a phone, a file link reviewed on a laptop at home, or a request actioned quickly between meetings simply because it seemed to fit everything else that was already happening.

The issue was not that staff were unaware of cyber threats. They already understood that cyber risk existed. The real difficulty was recognising when risk is present in situations that feel normal, collaborative, and professionally reasonable, and knowing when something that looks legitimate still deserves a second look. That is where the gap sat: not between knowledge and ignorance, but between awareness in principle and judgement in practice.

Our Approach

The session was built around the reality that, in collaborative environments like architecture, risk often looks exactly like normal work. Rather than centring the discussion on technical controls or policy language, the focus stayed on how cyber threats appear through everyday communication: emails, shared documents, Teams messages, and routine project requests that feel both familiar and time-sensitive.

This meant working through situations where nothing seemed obviously suspicious. A request fitted the project. A sender was expected. A message arrived at a point where a quick response would help maintain progress. Instead of treating these as abstract security examples, the session explored why those moments feel legitimate in the first place and why acting on them can make complete sense at the time.

Participants looked at how attackers can use publicly available information, project context, and normal patterns of communication to create messages that align closely with real workflows. The discussion was not built around hunting for dramatic red flags. It was built around understanding how legitimacy is constructed, how familiarity lowers scrutiny, and how routine collaboration can quietly shape decisions before anyone experiences the moment as risky.

The session also reflected the practice’s actual working conditions. Remote access, mobile devices, cloud-based collaboration, and Microsoft 365 all make fast, independent decisions more common. That is not a flaw in the way the business works; it is part of modern professional practice. The important shift was helping the team recognise where that environment creates moments that deserve a pause, a verification step, or an escalation, even when everything still appears to be in order.

By grounding the discussion in recognisable scenarios, the session stayed close to the reality of project work. The aim was not to slow people down for the sake of caution. It was to help them understand when caution is part of professional accuracy, and how verification can sit inside collaboration without disrupting relationships, workflow, or delivery. Throughout, the emphasis remained on judgement rather than rules, so that cybersecurity was understood as part of how good decisions are made in context, not as a separate layer imposed on top of the work.

The Outcome

The clearest shift was in how routine communication began to be interpreted. Before the session, many interactions were judged primarily on whether they fit the context of the project. If a request looked familiar and aligned with expectations, it was often actioned with little hesitation because that was what keeping work moving usually required.

Afterwards, there was a more developed awareness of how risk can sit inside those same routine interactions. The change was not about becoming suspicious of everything, and it was not driven by fear. It was about recognising that a request can make perfect sense in context and still require verification before action is taken.

That shift could be heard in the way participants described their thinking. What might previously have been reduced to “it looked normal for the project” became something closer to “it made sense in context, but I wanted to double-check it first.” That change in language mattered because it reflected a change in interpretation. The team was no longer relying only on familiarity as a sign that something was safe. They were becoming more comfortable holding two ideas at once: that a request could be reasonable, and that it could still deserve a pause.

There was also a stronger recognition of how everyday working habits contribute to overall risk. Accessing systems on mobile devices, sharing files across platforms, and responding quickly to messages no longer felt like neutral background activity. Participants could see more clearly how those small decisions, repeated over time, shape organisational security even when each one feels minor in isolation.

What changed, then, was not simply awareness of threats. It was the quality of judgement inside ordinary project work. Verification began to feel less like friction and more like part of maintaining accuracy, protecting client information, and supporting the integrity of the practice’s work. Cybersecurity became less of a separate technical concern and more of a normal part of professional decision-making. The result was a more considered approach to routine moments, with greater confidence in pausing when needed and a clearer understanding that the moments which feel most ordinary are often the ones that matter most.

Client Feedback

“In a short period of time, the session covered a wide spectrum of cyber attacks and practical ways to protect ourselves. The real-world examples made the training easy to follow and very engaging.
One of the most valuable aspects for me was learning how to defend against cyber threats in practice. If anything could be expanded in the future, it would be spending a little more time on protection strategies, although I appreciate that in a two-hour session it’s difficult to cover everything in depth. Overall, it was very insightful and useful.”
— Javier Jimenez Torres, Gamma Architects