<aside> 📃
This note comes from a fund system construction project where I served as the security assessment owner from the security team. My role was to act as the security focal point during vendor selection, follow up on security-related questions, coordinate vendor security discussions, and translate business and deployment requirements into security baseline considerations.
One of the key questions that came up during the review was whether the system should be delivered as SaaS / cloud-based service or deployed locally within the company-controlled environment. For this fund system, company policy required localized deployment because the system involved sensitive financial workflows, fund-related records, and potentially confidential internal data.
However, this case also made me think beyond one single project decision. Localized deployment is not automatically safer, and SaaS is not automatically unacceptable. The more important question is how to decide which deployment model fits a specific system, based on data sensitivity, business impact, integration boundary, and the security controls that can realistically be enforced.
</aside>
The main issue in this case was not simply choosing between SaaS, cloud, or localized deployment. The real question was how to judge whether a deployment model can support the system’s data sensitivity, trust boundary, operational model, and security control requirements.
For the fund system, localized deployment was required because the data and workflows were sensitive enough to demand stronger internal control. But that did not make the decision simple. Once the system is deployed locally, the company also becomes responsible for hardening, patching, monitoring, backup, disaster recovery, privileged access, and incident response.
On the other hand, SaaS or cloud deployment should not be rejected only because it is external. It may provide better scalability, availability, managed operations, and infrastructure separation, but it requires stronger review of data location, vendor access, encryption, auditability, incident notification, compliance responsibility, and exit strategy.
The key point is that deployment model decisions should follow the system’s actual risk profile, not a fixed preference for either cloud or local deployment.
The main case behind this note was a fund system assessment during vendor selection. What made this system sensitive was not only that it supported financial workflows, but that it could contain company wealth management and financing information, and potentially employee compensation-related data. For our company, this type of data is confidential enough that localized deployment became a hard requirement.
However, localized deployment was only the starting point of the assessment, not the final answer. Once a product is deployed inside the company environment, the security design still needs to hold up: separation between the user plane, management plane, and operations plane; WAF and traffic monitoring; database encryption and control of unnecessary plaintext exposure; separation of administrator privileges; MFA verification for sensitive instructions or high-risk operations; logging; vendor support boundaries; and operational accountability.
The more interesting tension in this case came from the bank-enterprise direct connection capability. The fund system itself needed to stay under local control, but one of its key channels still had to communicate outward with external banking services. If this capability were reviewed in isolation, an external-facing or SaaS-style model would not be unreasonable. It could sit in an isolated zone or a dedicated network segment, and then connect back to the internal fund system through controlled interfaces.
The design becomes more sensitive when that external-facing capability is packaged as part of a localized fund system. The real assessment point was not simply whether the product could be deployed locally, but whether it could be deployed locally without flattening modules with different trust levels into the same internal zone. The bank-enterprise direct connection should be treated as a separate connectivity layer, with independent network zoning, restricted access paths, clear interface boundaries, certificate and key controls, transaction logging, and dedicated monitoring.
This is why vendor selection should look beyond the deployment label. A vendor that supports localized deployment is not automatically a good fit if the product architecture cannot separate the external banking channel from the core fund system.
Segmented fund-system architecture showing business access, service flows, privileged operations, database isolation, and controlled bank connectivity. For a larger view, click the three-dot menu in the top-right corner of the embed and choose full screen.
Another consideration is whether the product can support security hardening after deployment. For a fund system, the security work does not stop when the system is installed. The architecture should leave room for behavior and traffic monitoring around payment and fund modules, such as unusual payment operations, abnormal transaction patterns, suspicious access paths, and high-risk interface activity. It should also be possible to integrate scenario-specific protections, such as enhanced anti-phishing controls for fund-related email workflows and WAF or traffic policies designed around payment system risks.
From the security team’s perspective, these post-deployment controls should already be considered during vendor selection. If a product cannot expose useful logs, separate critical modules, support monitoring integration, or provide enough control points for later hardening, the deployment model alone will not solve the risk.
AI/ML-based behavior monitoring and anomaly analysis will be part of the later hardening stage, especially for payment behavior, fund operations, interface activity, and abnormal access patterns, which I will discuss the model design and implementation considerations in a separate follow-up note.
The property management system became a useful counterexample. It was also a company system under vendor selection review, but the final decision was cloud / SaaS rather than mandatory localized deployment. The reason was not that the system had no sensitive data, but that its data sensitivity, business impact, and integration boundary were different from the fund system. In that case, cloud / SaaS was acceptable as long as privacy protection, encryption, access control, logging, vendor accountability, and compliance requirements were met.