Cognos Security Overhaul: Adapting Best Practices to an Existing Structure 

Oliver Feldenberg, October 6, 2025

During an engagement where I was helping with regression testing for a client, I was asked to look at the security structure and recommend changes for the new environment. Taking inspiration from Sonya’s article “Cognos Security – Best Role Structure and Capability Settings”, I made recommendations to simplify the client’s current structure, decouple capability and content access, and create documentation to help provide clarity on the structure and its intent. The original article suggests a scenario where you are using a brand-new installation of Cognos, but what if that’s not the case?  In this article, I’ll go through the steps I took to implement best practices on an existing security structure. 

Table of Contents

Cognos Upgrade 

The upgrade called for new servers, so I was able to perform a content store migration to the new server, then make my changes without affecting the current environments. Once we tested and validated the new security I created, we were able to continue with the system upgrade with only a minor change in schedule. If your team is considering a security overhaul, it would make sense to couple it with a system upgrade like in this example. Otherwise, you could implement the changes in your DEV environment first, like most other developments. 

Security Role Structure 

The first step is to set up the security role structure. Sonya suggests configuring four roles based on the licensing structure of Cognos: Analytics Administrator, Analytics Explorer, Analytics User, and Analytics Viewer. Basing roles around licensing makes understanding your license usage simple. In my client’s case, we didn’t want to match exactly to the capabilities of the roles, however we determined the licenses that would be used and cut capabilities away from there. 

Analytics Administrator 

For our administrators, we used the Cognos prebuilt System Administrator. There are only a few active administrators in the environment, so we wanted to grant them all full access. My client chose to go with named users for this role. 

Analytics User 

The Analytics User license had three distinct roles we created for it: developers, self-service users, and business users. Developers had the full capabilities of the Analytics User license while self-service users were granted the ability to build reports and dashboards from a self-service module in a specific folder, and business users simply were able to run reports. 

Analytics Viewer 

We had no users who only needed the Analytics Viewer or Analytics for Mobile User licenses, so we didn’t create any role for it. 

Analytics Explorer/ Data Modeler 

On the other hand, while we had no dedicated data modelers, we did create a data modeler role that adhered to the Analytics Explorer license. This was a future-facing decision. At this time, administrators take on not only administrative tasks, but they use Framework Manager to create packages for reporting. When the BI team has grown a bit, we imagine that we will have specific team members use this role for data modeling. Currently, we have no users in this role. 

It was helpful to create a spreadsheet that showed the license roles and capabilities next to the roles we created to quickly compare and audit what we were doing. A document like this is not just helpful for this planning phase, but for documentation that will save administrators time when troubleshooting or considering changes to the security.

This is a spreadsheet that has all the current Cognos licenses with their current capabilities (for Cognos version 12.1.0). Feel free to download this and plot your own team’s roles to quickly improve your documentation. For more information on capabilities, here is a link to IBM documentation on license roles, and here is a link on documentation explaining capabilities. 

For this project, we decided to make as few changes to the groups as possible. My client had outlined a new folder structure based on the groups they had, so all the content security would be based on this. These groups were already connected to AD groups, so they were managed by another team. 

Resetting the Capabilities 

With the planning phase finished, I needed to go into the new server and execute the plan quickly, so we could continue with the system upgrade. The first thing I did was create the roles in the Cognos namespace and add their members. Next, I went into the capabilities and removed everything for a clean slate. Something important to note here is that when you remove all groups from a capability, the capability reverts to default settings. The “Everyone” and “Server Administrators” populated the capability. 

To remove these, we will need to move onto the next step: add our new roles to the capabilities. In our example setup, System Administrators don’t actually need to have their capabilities specified. It’s a default Cognos role that automatically inherits all capabilities no matter what. If you find that you have capabilities that have no groups or roles assigned, you can simply remove “Everyone” and keep “Server Administrator”. Just be sure not to assign anyone to “Server Administrator” if you choose this path. 

Note: Because we were working with a new folder structure, I also had to follow a process to move reports and set security at the group level. An initiative like this will require further testing to validate. If you have an existing folder structure your team is happy with, you could maintain the security assignments you already have. 

Double check that capabilities are assigned how you want them, and make sure it is consistent with your spreadsheet (documentation is only useful when it’s accurate). Also make sure that your new roles have the correct membership. I created a spreadsheet that mapped out group memberships to ensure we assigned everything correctly. A document like this can also be helpful for your team, so long as they maintain it, to quickly audit and plan, just as much so as the capabilities matrix. 

Testing Best Practices 

Now, it’s important to test and validate the roles you created. The best practice is to create test users for each group in your environment, but in my client’s case we weren’t allowed to do this. Instead, we had to get users from different groups to log onto Cognos and have them try different things. Don’t only check for what each group should do, make sure they don’t have access to things they shouldn’t. It can help to write up a set of instructions for test users to follow and allow them to fill in the instructions with their results. For example, my developers should be able to create reports, so I instruct them to click new and start building a report. I would also give this instruction to my test business user with the expectation that Cognos would not allow them to do this. 

As an administrator, you should also check license usage and see if Cognos is recognizing the licenses you intended. It will only show usage for users who have logged into Cognos, so you can count how many licenses you expected based on the makeup of the test users. This is a quick way to verify the roles were configured at least according to your licensing. 

Regression Testing 

With testing complete, we moved on to regression testing for reports and out of scope for this article. The new, documented security structure was simple for my client’s administrators to adapt to and simplified security conversations going forward. Since the upgrade, they have added another role to their structure. The BI team is now empowered to revise their documentation to reflect new initiatives and communicate clearly with one another. 

Final Thoughts 

Although rethinking security in an existing Cognos environment can seem like a big lift, the consultants here at PMsquare are here to help you. If you have any questions or would like PMsquare to provide guidance and support for your analytics solution, contact us today.