Policy approval best practices

Starting to roll out my first Eramba instance and am a bit stuck on best practice regarding policies. I understand the options available and how to configure, just not sure what is best given our use case. We have numerous policies, all of which require multiple approvals to be valid. Currently, we’re using our wiki to post the policies and run the approval process. Policies must be reviewed and re-approved at least annually, but we have several that tend to be updated a couple times a year.

Now to Eramba, my dream configuration would have the policies all located inside Eramba with an approvals and versioning process built in, but it seems that doesn’t exist. I could use the URL option and link back to our current wiki setup, but then how would/should the audit work, would I just be periodically running an audit to make sure that a policy has a valid approval, even if its a couple versions later than the last time we did the audit? Also, if that is the case, is there a way to do a bulk check where a single audit can be made to apply to all policies (so, for instance, once per quarter, we have a single action item to make sure all policies have valid approvals instead of doing and documenting each policy individually).

I’d appreciate any feedback on how others are managing this piece and what does/doesn’t work effectively.

Thanks

hello!

have you tried to check the videos? there is a full example on how a policy is uploaded, its reviews (this is how we keep records of changes on the version, we call audits something different) are supposed to be used, etc.

it should give you an idea on how eramba works. there are no user-configurable workflows so the back and forward of an approval must be done on emails or some other system and then uploaded to the review record.

have a look there , it will hopefully help

I did watch that, and have read all the documentation as well, which is why I understand that various ways that it can be configured. Now I’m just trying to figure out what the best configuration option is for my company and am looking for any recommendations based on our use case the community might be able to provide.

Just thinking out loud here - I see two requirements for Policy approvals - 1. All policies are reviewed and approved on at least an annual basis and 2. All policies that are changed are approved.

For 1, that’s just setting your review interval and running with it.

For 2, with the assumption you link back to your Wiki, I could see adding a Control that’s performed quarterly to see if there are any policies with modification dates since the last approval and confirm that approvals were applied in Eramba (this would be outside of the Policy Management process screens).

The other consideration here is whether your policies are too granular - in general, they shouldn’t change significantly year over year unless there has been a major organization change or a new set of requirements. Pushing some of the policy specifics into Standards and Procedures may be worthwhile (assuming you have a higher threshold for approval of Policies than those). The other thought would be - do we really want to make this update now or wait until the next policy cycle?

The other consideration with policy changes is communication to end users. When you look at various audit requirements (i.e. SOC 2 where I tend to live), if you change a policy you then need to communicate it to relevant individuals. To me, this makes an additional point for trying to limit updates to annually unless your face is melting in need of a change…

@david.schroth I think you hit the two use cases perfectly. For reference, the majority of our policies are stable and undergo annual review with no real changes during the course of the year. However, there are a handful that are still in the maturation process and get updated as we realize that something is missing or not right, or that we need a new policy to cover something that hasn’t yet been addressed. The number of those policies is also diminishing as our entire program continues to mature. We do have to train users on changes, but that’s proven to be fairly easy to do as training is the fundamental purpose of our product, which we use to meet this requirement as well.

What I’ve actually been thinking about doing, and please do correct me if this is an idiotic idea, is to use the URL linking to the policies on our wiki, where the policies will live and the approval process will take place. The remove all of the reviews from all of them, resulting in policies that always show good. I can then map those policies to the various compliance requirements to show how they function in context and the always good status prevents any problems with the compliance or risk modules.

Of course, we would still need to be sure that the policies are properly approved, and for that I would create a separate “master policy” checker thingie entry into the policy list which would not be an actual policy but would contain a quarterly review requirement to check that all existing policies have appropriate approvals at that time.

It’s a bit wonky, but I think that would meet all the requirements for the program and also allow us to demonstrate at audit time which polices relate to which requirements, and also to demonstrate that we do actively ensure the policies are properly reviewed and approved.

Does that make sense? Am I out of my mind?

Your solution could certainly work - at the end of the day, you’re accomplishing the policy approvals and keeping them approved through what you want to do.

The caveat that I’d encourage you to think about is that you’ve made the decision to spend resources (time and cash) to implement Eramba in order to consolidate all of your compliance activities into a single “all knowing” system that should be your one stop shop for everything when you need to demonstrate compliance. While the “one stop shop” may not offer an ideal situation for some of your use cases, I’d argue that there’s benefit to keeping everything in one place to keep things as simple as possible. Sure, the policy workflow may not feel simple, but think about keeping the program evergreen - your document repositories and locations will change over time and different people will be responsible for compliance in the future. By doing things outside of the “one stop shop”, it increases risk that the ball will get dropped in the future.

That being said, I could probably make just as interesting of an argument going the other way… so perhaps thinking through the ‘ideal’ here would turn into a good feature request for future improvement…

I’ve been trying to figure out how to make Eramba a one stop shop, and feel that I can do it everywhere but here. If Eramba had an approval workflow that would allow me to do a multi-approver setup within, then I definitely would do it here, but until that function is built, I don’t see an alternative other than removing the policies from Eramba entirely, which would only make things more separated then the work around I proposed.

I’m also wondering if this is the type of thing I should be creating a feature request for. Obviously, it would be helpful to me, but not sure that its something that most users would find useful or really something that the product should be doing.

Mostly asking from a devil’s advocate perspective, but why would multiple policy approvals be required? Is there not an approver that can serve as the “buck stops here” approver? Could part of their approval duties be that they are required to gather all other necessary approvals and store elsewhere (since Eramba won’t do for that), but the key control is their approval rather than a group?

As referenced in the 2.6.0 release notes, workflows of some sort are in the pipeline for prior to the end of the year. Exactly what that will entail, I’m not sure - maybe @eramba can point us to the thread that’s being worked for it and whether it would be applicable in this scenario (looks like #389 “User Defined Workflows”)…

As currently designed, we have an exec management team that approves policies, hence the requirement for multiple approvals. That said, we could change the process to have a single approver, but since they would still need to get the other people to approve and document that, I don’t see that it makes much difference in the long run.

I am encouraged to see workflows on the way, hopefully they’ll do what we need (I’ll hold off on making any requests until I see what they put out).

I appreciate your playing devil’s advocate, it’s good to have someone make you think along different lines.

eramba does not have user defined workflows that reflect the organisation “step by step” process that gets something approved. this existed, got deleted in 1.x for various reasons and will exist again towards the end of the year.

how people handle things today and for the last years?

1- you upload policies, your “approval process” is offline (you use emails, etc) and once the approval is clear you update the reviews on eramba (with the updated version number and url/attachment/content) and attach the emails you used as an attachment to the review.

notifications in eramba can be used to remind people reviews are due soon and they should get prepared. you can also setup reports that come to you every week reminding you the list of reviews due in the next couple of weeks or what reviews already have expired. there are many possibilities there.

2- you want users to upload the policies they have drafted as newer versions to eramba directly, eramba will send emails with the warnings, the user clicks on the email, logs into eramba and will be redirected to the exact review record that is pending. they click on comments and attachment and write there where the url for the new version is or what is the new drafted policy document as an attachment. if you use the right permissions, the user can not edit, remove or do anything with the review so they just provide feedback.

you can configure emails that trigger on comments and attachments (as they are provided or as a digest) , so when they provide any feedback to the review you and them will see that as an email notificaiton. you can login and provide your opinon and so go back and forward until the policy terms are clear and approved.

once things are clear the grc team (generalising here…) can edit the review and complete it with the updated version, content/url/attachment and set a next reiview date. in essence the interactions of the workflow end up being documented on the review as comments and attachments.

3- you use the feedback option of a notication, which allows you to define a portal message and users to upload comments and attachments…but is only ONE WAY, meaning once they provided somethin the “feedback” is considered done and no further uploads are allowed (please see the notification documetnation on feedback)

4- your workflow approvals exist in some other tool (sharepoint,etc) and you dont want eramba for that, you just want eramba to link policies to risks compliance, etc (the policies will hold the url reference to the actual place where they are) and so you upload policies to eramba and remove (delete) the “future” review records so you never get the “review expired” warning on the system.

We have been running this project for many years, the most common option is #1 and then #2 , option #3 is very new (feedback only exists for a few months).

eramba is 3000 EUR or so a Year - an hour of consulting is 80 EUR. Not spending 4 hours of consulting to make sure you understood the documentation well and have an opinion from the team that has been implementing eramba for a long time all around the world is in my opinion a mistake. We dont force people to spend into onsite trainings or consulting hours (as any other grc company would do) because the vast majority of customers dont need it, but if you think you need it … i would not even doubt it.

There you go - our advice!

Thank you for the detailed answer. It looks like what I’m thinking is closest to option 4, but with the workflows coming, I may need to rethink it a bit. I did put a few hours of consulting in the budget, and fully expect to use them at key points to ensure a solid implementation, but have found going through the process to work out most of the kinks makes the consulting process much more efficient and successful. I expect that we’ll be getting some time with you soon though as the policy section was the only area of the application that I’ve had difficulty finding a good course with. I did play with the community edition for about a month before purchase, and the approach to everything else was clear as could be.