Start with a scenario. At a mid-sized manufacturer, an accounting clerk clicks a link in an email that looks like it came from her bank. The page is an exact copy of the real one; she types her username and password. The next day, someone opens a valid session on the company VPN with those same credentials. The EDR stays quiet, because as far as it can tell, this is a legitimate user. Three days later the file servers are encrypted.
No step in that chain involves an exotic vulnerability. No zero-day, no advanced exploit. Just a stolen password and a system that treats it as legitimate. The question: why couldn't the most expensive endpoint product stop it?
Incidents like this are far more common than people assume. In 2022, an attacker at a ride-hailing giant compromised a contractor account through social engineering, logged into the corporate VPN, found privileged credentials embedded in a PowerShell script on the internal network, and spread to nearly every cloud and internal system. There was no zero-day involved; there was a stolen identity and permissions far broader than they needed to be. A smaller-scale version of the same story plays out somewhere in Turkey every week.
The category evolved from spam to email security
Email threats went through three eras. In the 2000s the problem was called spam, a volume nuisance, and the fix was called antispam. Today the problem is a targeted attack surface covering phishing, BEC and account takeover; the category is called email security. We are now in the third era: AI-assisted attacks.
The third era is different because it destroys the cues that let us tell an attack from human writing. We used to spot a phishing email by its typos and broken grammar. AI erases those cues. The message arrives in flawless language, tailored to the victim and aware of context. Deepfake audio can imitate a phone call. As attacks become indistinguishable from humans, trusting a single filter gets riskier.
Counterintuitively, the AI argument strengthens the "architecture first" thesis rather than weakening it. Even a flawless phishing email achieves nothing on its own while MFA and strict segmentation are standing. The stolen password hits the second factor; even if it gets through, lateral movement runs into the walls between zones. For one perfect message to bring down an entire organization, there has to be a defenseless architecture behind it.
Security is not a product, it is a sustained discipline
The industry's sales language talks about security as a product. Buy this box, renew that license, you are protected. In reality security is a process, not a state. A firewall is correct on the day it is installed. Three months later its rule set has decayed under a pile of emergency access requests. A patching policy is valid on the day it is written; with nobody enforcing it, it means nothing six months later.
Operations produce the value; installation is only the starting point. A good month is a month in which nothing happens. The invisible work behind that silence is the daily grind of triage, patching, audits and reviews.
Single source of authority and separation of powers
The backbone of the vCTO model is a governance principle: separation of powers. In information security it has three parts. Segregation of duties keeps any critical process from being controlled end to end by one person. Least privilege gives every identity only the minimum rights it needs to do its job. Separating use from control is the most critical part: whoever uses a system cannot also control that system's security, its logs and its backups.
The operational form is the single-source-of-authority model. Privileged access and configuration authority for the layers under our responsibility are concentrated in one place; the parties who use the systems work within their limits, fully logged. This should not be read as a bureaucratic exercise; it is a mathematical necessity. When one person holds the rights to use a system, manage its security and access its logs, three defenses collapse at once: prevention collapses (they can lift their own restrictions), detection collapses (they can erase their own tracks), accountability collapses (who did what can no longer be separated).
The standards demand exactly this. ISO/IEC 27001:2022 A.5.3 defines segregation of duties and A.8.2 privileged access management. PCI-DSS v4.0.1 Requirements 7 and 8 require need-to-know and unique identities. NIST 800-53 AC-5 and AC-6 draw the same line. None of these frameworks say "buy a strong product"; they say "separate the user from the protection."
Public incidents show why the principle exists. In the 2022 case above, the attacker moved from a single contractor account all the way to the privileged access management system, because permissions were far too broad. In 2023, an identity provider's customer support system was accessed with stolen credentials, and customer data was reached from there. In both cases the thing that failed was not a product but the permission architecture. A strict least-privilege model would have shrunk the blast radius of the initial access from the start.
There is also a practical side. With two separate privileged authorities (the organization's own admin and the external provider), responsibility blurs the moment something breaks. Two-headed administration makes accountability impossible to trace. That is why we act as the single authority for the layers under our responsibility, while daily operations and L1 monitoring stay with the organization's own team. The team observes, we execute. Even in an emergency, privileged actions stay in one place; the internal team's role is isolation, physical intervention and escalation.
You cannot protect an asset that is not in your inventory
The most instructive findings in the field tend to come from the least expected places. In a recent engagement we hardened the internal backbone: redundant Active Directory, extensive hardening policies, a high-availability virtualization cluster that had passed failure testing, central security monitoring covering every server. The inner door was solid. The highest-leverage risk turned up somewhere unexpected: the outer door.
The organization had dozens of branded domain names. Websites, email, brand identity, all of it hung off those domains. And this asset class appeared in no corporate inventory. The entire portfolio sat in a reseller account one employee had opened in his own name, and the door to that account was protected by an SMS code sent to a personal phone. Looking for a villain here would be a mistake. The employee had solved a need pragmatically; nobody had ever formally asked him for a corporate process. The root of the problem was that no ownership had ever been defined for this asset class.
The business meaning is heavy. If that employee left, failed to hand over the account, or had his phone line hijacked in a SIM swap, the organization could lose administrative control over the internet identity of all of its brands. Domain renewals hung on one person's attention; the corporate calendar had no record of them. An expired domain could be snapped up by a third party and used for brand impersonation or phishing.
The fix is clear and carries no personal consequences: move the domain portfolio onto a corporate, role-based, auditable footing. The account is transferred to the corporate legal entity, SMS gives way to app-based (TOTP) or hardware-key (FIDO2) authentication, auto-renewal and alerts are set up for every domain, and every operation is written to an immutable audit trail. We do this through our own managed panel, Ops Hub: role-based access control, TOTP-based 2FA, automated renewal tracking and an immutable audit trail. The portfolio becomes centralized, corporate and visible. The lesson goes beyond domains. Every organization has an asset class nobody has inventoried, hanging on one person's attention. Security work starts by making it visible.
Email authentication: free, and mostly not done
In the same engagement we found the active sending domains open to spoofing. Three mechanisms prevent fake email being sent in a brand's name. SPF defines which servers may send mail for the domain. DKIM stamps every message with a signature that cannot be forged. DMARC says what to do when the first two fail, and sends you reports. Without all three, the protection is incomplete.
In the field the picture is usually the same: SPF present, DKIM on a few domains, DMARC nowhere. Without DMARC the receiving side cannot enforce an alignment policy, and reports of fake email sent in your name never reach you. The fraud is both unobstructed and invisible. Yet closing this gap is free; it only requires publishing the right DNS records.
The rollout has to be gradual. Starting straight at reject (p=reject) can also block legitimate mail such as ERP notifications or web forms. So monitoring comes first (p=none with reporting on): every sending source becomes visible and the legitimate ones get verified. Then quarantine (p=quarantine) is introduced at a stepped percentage. When the reports are clean, the policy moves to reject (p=reject). Parked domains that never send mail are locked down defensively in a single pass (SPF -all, DMARC p=reject, null MX): they have no legitimate mail to block, so the risk is zero, and most of the portfolio leaves the attack surface in one move.
Architecture works first: redesigning remote access
The root cause of a ransomware incident is usually badly managed remote access. A setup where everyone enters the same wide VPN, shared credentials circulate, and nobody logs who accessed what and when, opens the whole network with one stolen password. Adding products without fixing the architecture is wasted investment.
In the right design, the general-purpose VPN is removed. Remote access is defined per person, MFA is mandatory, the user lands only in the segment they need (not the flat network), every session is logged, and access is opened just-in-time (JIT) where appropriate. There are no shared accounts; everyone signs in with their own named account, and when an installation ends those accounts are disabled until the next maintenance window. Even an application owner gets no local administrator rights on the server; their authority stays at the application layer. Reopening the same attack vector becomes structurally impossible. Design protects, not products.
Open source first, but pragmatic
Wherever it fits, we move organizations to open source: Proxmox, Wazuh, Zimbra, Nextcloud, PBS. The value cuts two ways. License costs disappear, spending drops. Auditable source code and the absence of vendor lock-in increase control. One warning belongs here: open source is not automatically more secure. Transparency, auditability and correct configuration produce the security; the license model alone guarantees nothing. So we are not dogmatic about it. Open source goes where it fits the need; where it does not (Proofpoint and FortiGate, for example), the right commercial product takes the slot.
Bringing banking discipline to the mid-market
There is a concrete track record behind this approach. Since 2015 we have run more than 50 PCI DSS certifications with zero failures, as Turkey's first Level 1 service provider. On the ISO/IEC 27001 side we employ two TSE-certified internal auditors. In email security we have over 17 years of experience: as Barracuda's Turkey reseller from 2007 and its distributor from 2008, we lived the category's evolution from spam to email security first hand. Today we continue the same work at a higher level as a Proofpoint partner.
The standards of the most tightly regulated sector can be applied to an organization facing the same threat with less regulation. With Law No. 7545 on Cybersecurity entering into force in March 2025, the private sector's security obligations in Turkey now rest on a legal footing as well. The discipline matured in banks and e-money institutions does the same job at a mid-sized manufacturer.
Installation happens once, security happens every day
An infrastructure is built once; security is maintained every day. You can turn the inner door into steel, but you cannot protect an asset you never put in your inventory. Separation of powers does no work on paper; it has to be operated daily. What protects the investment in the installation is the continuity added on top of it, day after day. In the vCTO model that continuity stops being a service bought from outside and becomes a responsibility embedded inside the organization. That is what produces the silence of the good months.