Unfortunately, in most fields, true experts are few and far between. Every genuine expert is buried under a crowd of imposters. These imposters have carved out a place in the industry, pieced together a patchwork of knowledge, and to the untrained eye look no different from the real thing. They serve a purpose, but they don’t truly understand the field they operate in. Real experts don’t rely on rigid rules — they have deep conviction, so they don’t need them.
— from The Turtle Traders’ Rules
BU Security Governance
For BU security governance, here’s a summary of security work I’ve done across two large organizations. The first was at Alibaba Group, focused on security within the Local Services business — which included Ele.me (and Ele.me Star Selection, formerly Baidu Waimai), Koubei (technically under Ant Group), and Keruyun. I haven’t seen much public material on other BUs there. The second was at PayPal Group, primarily around GoPay’s security program, along with reference material from PayPal’s BU security work across acquisitions over the past few years — Curv, Honey, Simility, Venmo, Xoom, Hyperwallet, Braintree, and others.
Here are some takeaways:
For the parent group, BU security should be treated as a time-boxed project with a defined duration, not an open-ended ongoing investment. Flip that around for the BU itself — once you take ownership, it requires sustained attention.
At Alibaba, it seemed relatively rare for a BU to have its own dedicated security team. At PayPal, it looked like a more common setup — partly because financial services have localization requirements built in, which pushed PayPal to build a team specifically for BU security.
Following standard project management practice, you have to go find your Stakeholders and get the project signed off. Based on your budget, build a resource pool — headcount (FTE / part-time / contractors, Engineers / PMs / Ops), plus tools and infrastructure. PMs act as the connective tissue between the BU and the group, coordinating resources and helping both sides get through the implementation.
Both Alibaba and PayPal did this well, which makes sense — mature organizations have solid process frameworks for managing resources. Alibaba’s execution speed was honestly faster, though when you’re an individual contributor it can get overwhelming — you might still be getting paged after hours. In practice, things shouldn’t be that chaotic; running around with your hair on fire is how mistakes happen. For some of the tasks in point 2, some companies hand this to their InfoSec BP engineers. I think that’s roughly how Didi does it (not talking specifically about BU security governance, more the general security build-out process).
During the program, you need to check whether the security infrastructure you’re relying on can actually keep up with business growth and change — for example, if the business scales up or the IT architecture shifts, can your security products handle the new performance and capacity demands? And are you meeting customer needs (both security’s internal customers and the company’s external customers)?
Take Alibaba as an example — by 2019 the whole group was already pushing a cloud-first mandate. Ele.me was in the middle of consolidating from 4+ on-prem data centers, starting with moving traffic ingress to the cloud while data was still flowing back to the data center. Later on, the New Retail business moved entirely onto Alibaba’s tech stack and deployed into the “bullet environment” (roughly: Alibaba’s private tenant on public cloud, for internal use). That meant reworking and sunsetting middleware, merging things together. You had the old Baidu Waimai stack, the original Ele.me stack, the New Retail stack, and Koubei running on Ant Group’s tech stack inside Ant’s data centers. Throughout this cloud migration, designing solutions for traffic scrubbing, fingerprinting, and end-to-end coverage had to account for the moving target of business changes. Same story at PayPal — part of the group was on GCP, some on AWS, and certain BUs spanned three or four clouds plus on-prem. Some used IaaS, some PaaS, some deployed cross-cloud on k8s. All wildly different, and the security build-outs reflected that.
During the program, know who your customers are and what customer-centricity actually means.
Being customer-centric starts with recognizing that you can’t treat all customers the same — and that’s not about playing favorites. It’s about correctly identifying customers and understanding their relative importance on top of delivering the base service. If you want to sound cool about it: Business is Business. For more on this, there’s a book called Customer Centricity: Focus on the Right Customers for Strategic Advantage worth checking out.
The whole point of the program is to bring the BU’s security posture up to a baseline and hand them an operable security framework. During the build-out we apply the weakest-link principle; once it’s done, the BU becomes one stave in the barrel (of the group / ecosystem). This is especially true in financial services, where banks, payment providers, and businesses all interact through specific authorized channels — if a business entity is compromised, it effectively punches a hole in the payment provider’s authorized access (and that hole can cross systems, institutions, and regions).
If the BU has no security team, then it just becomes a unified build-out, and the “operable security framework” you hand over is essentially identical to the group’s. For groups where BUs don’t have strong ecosystem dependencies, the weakest-link problem in the ecosystem probably isn’t a real concern. When handing over an operable security framework to a BU, you’re generally more focused on the Site environment (production workloads); Corp-side (corporate network) stuff tends to follow unified standards — account management, authentication, endpoint protection, all that should be standardized.
Do you actually need standardization and unification?
See point 5 regarding whether the BU has its own security team. This question stuck with me for a long time. Based on my Local Services experience, I used to think unification and standardization were clearly better. Maybe it was because Alibaba had a strong culture pull, or because it let you raise the security baseline while giving BU security folks a shared platform to work on — contributing data that complemented the group’s view. But I don’t see it that way anymore, and it’s not that easy to implement either. The division of authority between group and BU is too sharp. My current take: not everything needs to be standardized or unified. If something adequately meets the current scenario’s requirements, that’s enough — because even if you rebuild it, the goal is still just to meet current scenario requirements. Some BUs use Fortify, others use SonarQube; some use Twistlock, others Aqua; some use SafeNet HSM, others Cloud HSM. As long as it can handle compliance pressure, support current business operations, and meet the security baseline, there’s no good reason to blow everything up and start over.
Where you have a gap in one area, compensate with something else. Balance the long-term proper solution against short-term tactical fixes that matter right now.
For example, financial companies typically go through license renewal every five years and annual license updates — failure means the business stops. If you don’t have an automated access management system in that process, can you shift the weight from technical controls toward policy + operations (tech, policy, ops — those three pillars)? You could route every permission grant through the existing ticketing system for approval, then embed the ticket number in the corresponding access grant as a required audit trail, and enforce it as a mandatory policy. Same idea applies to data: how do you make sure all sensitive data has actually been fully deleted? Even when you’ve technically identified the relevant storage assets and wiped them through multiple methods, you should still sign a legally binding contract or guarantee with the implementing party.
After you’ve handed over a sustainably operable security framework — the BU now has its own localized operations capability.
At that point, periodic reporting is appropriate. The group stays as a dotted-line relationship, syncing on status. On the reporting side: during the build-out itself, weekly syncs with implementers and monthly reports to Stakeholders are necessary.
The technical side is similar across situations. Within each security domain, establish basic security controls and the minimum acceptable security level.
Think application security requirements, data security requirements, infrastructure requirements, and so on — then have tech, management, and operations work together to make it real. One thing that comes up is whether you’re building from 0 to 1 or from 1 to N. M&A targets generally have some existing scale and presumably some security foundation, however mature or immature. But in practice some companies are fully cloud-dependent with no core internal security team. There’s also the possibility that post-acquisition the whole thing gets torn down and rebuilt — sometimes the acquisition was purely for the product and its user base. When a mature BU security framework is already in place, building a BU’s security from 0 to 1 can actually be more effective than going from 1 to N. Beyond that, there’s the morale side of an acquisition, and the question of whether to rebuild the security team from scratch.
Afterword
I’d been planning to write about BU security governance for a while. But when it actually came time to put pen to paper, it wasn’t easy. I’ve personally gone through some 0-to-1 security build-outs, and I’ve also been on the receiving end of a group-level enablement program (as the security side being integrated). Looking across these similar processes with their different outcomes — after spending time reviewing those experiences and organizing my notes — I became more aware of how much I still don’t know. Staying in learning mode is an endurance game. That’s also why I put that passage from The Turtle Traders’ Rules at the top: there really are too many “experts” out there.
Lately I’ve been reading some books and a few articles, building up a lot of notes. Feels productive, but also exhausting. Learning takes more out of you than work does. For this post specifically, there’s a lot of material I could’ve drawn on, but can’t write here. Every BU security project is a solid case study in building something systematic.