When the subject of corporate data security comes up, the conversation usually turns to outside influencers such as hackers, malware, internal espionage and high-profile breaches. Those are issues that every company should protect against, but they are not the topic of my blog today. What I\u2019d like to address are basic security measures that will protect your data (and your ERP investment) from the mistakes of well-intentioned employees.<\/p>\n
It may seem difficult to believe, but I have a customer that continues to allow its employees to log in to their ERP software without a password<\/em>. Why? It\u2019s faster and easier, they claim, they trust their employees, and they have a strong firewall to protect them from external threats. Besides, their data is backed up regularly, and not interesting or high-value enough to attract attention from the criminal element. So what\u2019s the big deal?<\/p>\n From the support-desk perspective, it\u2019s potentially a very<\/em> big deal. I have seen it happen in the past, and I will no doubt see it again: a user can\u2019t complete his job because some admin task hasn\u2019t been done. Thinking that they\u2019re being clever and helpful, they simply log in as Admin and make what they believe are appropriate changes.<\/p>\n Some users have gained a little ERP knowledge over the years \u2013 just enough to make a little change and create a very large and often complicated problem. With the best of intentions, they\u2019ll commit an admin faux pas<\/em>, such as changing the module setups or invoice numbering while other users are still on the system. It takes, typically, a deeper level of knowledge to know that there are tasks that need to be performed when users are not logged in, and that some setup options, once selected, should not<\/em> be deselected. You often need more-than-superficial knowledge to make the setting change without impacting on the whole module.<\/p>\n Administrator rights for accessing a change of settings should not be gifted to just any old Joe. Placing all of your users into the Admin group is never a good idea. Make an investment in security and efficiency by setting up your users in groups that match their tasks. In the long run, doing this will save you time, and it will also make it harder for accidents to happen. If users have multiple roles within a company, they can always be setup with sub-groups that allow them to complete their appointed tasks.<\/p>\n You can easily take this one step further, by setting up customised \u201cRoles\u201d. This makes users\u2019 screens less cluttered, allowing them to focus exclusively on the fields they need.<\/p>\n Role-based security is an optional feature that consolidates existing security functions within SYSPRO, allowing them to be configured by role. Enabling an administrator to assign an operator to a role provides a much simpler mechanism for managing security \u2013 especially when dealing with a large number of users, or when adding new ones.<\/p>\n Role-based security consolidates the following ERP features:<\/p>\n SYSPRO ships with a list of standardized roles within Role Management. When Role Management is set up for the first time the option is provided to import this list, which contains generic roles that SYSPRO has identified as part of any organisation which purchases, manufactures and distributes items. The list can be imported and maintained in the organisations structure as required, and will help with the speed of setup and administration. Importing the standard roles does not delete or overwrite any roles you may have previously defined.<\/p>\n Knowing When (And How) To Purge<\/u><\/strong><\/p>\n Since we\u2019re talking about internal security and well-intentioned mistakes, let\u2019s spend a moment on the \u201cPurge\u201d function in all the sub-ledger modules. Purge means delete. Definitely an Admin-Only function! Once purged, your data has been wiped away \u2013 it\u2019s gone forever, unless you have a vital, valid backup. Some users may not realise the irrevocable nature of the Purge command, and that is why security around purge programs needs to be exceptionally tight.<\/p>\n For legislative and tax purposes a company needs to keep a number of year\u2019s records on file. Within the Module setup, on the History Tab, you may select the number of months to retain records. This should be double checked before the Purge function is run. And when the time comes to purge I always recommend that the company be copied into a \u201ctest\u201d company before the command is given \u2013 this access should also be an Admin Only task.<\/p>\n For more information on how to ask for help, watch this brief video:<\/p>\n\n