On-premises software typically means that it is installed on a server under your control. On-premises used to literally mean that the server was also located on your premises, in a server room somewhere; however, nowadays, on-premises can still be hosted in the cloud, but the cloud is under your control rather than the vendor’s.<\/p>\n\n\n\n
In this post, we\u2019ll explore the pros and cons of choosing an on-premises grc platform<\/a> or on-premises risk management<\/a> platform rather than use a typical cloud-based SaaS solution.<\/p>\n\n\n\n As you own the server the data is stored in, you are more in control who and how accesses it. Keep in mind though that nowadays vendors often require some network connectivity between the application and their servers – either for lisence validity checks or usage analytics. In these cases, it makes sense to audit these conenctions and exactly what data is sent “home” during your vendor onboarding process. This also comes in handy when the vendor doesn’t quite meet the compliance requirements you need – some of these risks can be mitigated with on-premises hosting.<\/p>\n\n\n\n This can be good for security as you can choose to add more layers of security like VPNS, IP whitelisting that are often not features that vendors offer out of the box in their SaaS offerings.<\/p>\n\n\n\n There are different rules and regulations about data residency around the world which may require certain type of data be physically hosted in that country. Although for most companies their information security and risk management information would probably not go under this rule, it still might be a soft requriement for government agencies, and critical service providers. <\/p>\n\n\n\n When you\u2019re in control of the infrastructure, you\u2019re also responsible for it. <\/p>\n\n\n\n That means applying patches, managing uptime, renewing certificates, rotating backups, and making sure everything keeps running smoothly.<\/p>\n\n\n\n If your team doesn\u2019t have a strong DevOps or IT operations capability, this can quickly turn into a pain point\u2014or a security liability.<\/p>\n\n\n\n And of course you also need to pay for everything that comes with it – servers, backups etc.<\/p>\n\n\n\n In cloud-based platforms, vendors roll out updates automatically.<\/p>\n\n\n\n With on-premises deployments, you often need to manually install updates\u2014or at least schedule and manage them yourself.<\/p>\n\n\n\n This introduces delays and risks if your team falls behind on patching. It also means feature updates and security improvements might reach you later than cloud users.<\/p>\n\n\n\n SaaS platforms usually let vendors diagnose issues directly\u2014often without needing much from your side.<\/p>\n\n\n\n But when the software runs on your servers, the vendor might not have access to the logs or systems they need to troubleshoot quickly.<\/p>\n\n\n\n Support requests can turn into lengthy back-and-forths with log files, config dumps, and screen sharing.<\/p>\n\n\n\n The more custom your deployment is, the harder it becomes for the vendor to help you effectively.<\/p>\n\n\n\nPros of On-Premises Deployment<\/h2>\n\n\n\n
\n
\n
\n
Cons of On-Premises Deployment<\/h2>\n\n\n\n
\n
\n
\n
When On-premises GRC Makes Sense?<\/h2>\n\n\n\n