We’ve talked before about the importance of security in protecting your organization’s data. In our most recent post on the subject, we discussed, in detail, the process of establishing good security measures within your applications. But that’s only part of the equation. A successful security strategy should also include a close look at the broader security environment in which you’re doing your reporting.

To make sure you have all of your bases covered, we recommend take the following steps when building a security strategy for your institutional data:

Step One: Complete a Security Inventory

Like with any institutional decision-making, let the data drive your security decisions. Before you get into the finer points of your security structure, it’s important to take stock of all of the people and programs that will need to be accounted for.

  • Identify the systems you wish to use with Argos: As an enterprise tool, Argos can be used to report against a variety of systems. Create a list of these systems and verify that MAPS and Argos are capable of working with these systems.
  • Identify the owners of the systems: It is important to identify the individuals responsible for the systems you wish to use for reporting. Some systems may have multiple owners, or ownership may be fragmented, with a variety of individuals having responsibility for different parts of the system. The system owners can explain the existing security setup for the system. This is important information that will be used to configure MAPS and Argos security.
  • Identify the users of the system and the roles they will fill: You are certain to have a variety of users with different needs and skills. While it is not necessary to identify every individual user of the system at this stage, it will be useful to know the different types of users, and how they will be using the system. Start dividing the users into roles according to the tasks they perform and the level of access they will need. These roles will be used to set up the MAPS and Argos security roles later on.


Step Two: Review Your Security Goals & Policies

As you are setting up a new software environment, you’ll want to take the opportunity to review the relevant security policies at your institution. Based on that review, you can establish some goals that your security setup will help you achieve.

  • Review your existing policies and procedures as they relate to data access: It is tempting to study the dozens of security features in MAPS and Argos and simply start implementing those that sound most useful. This approach can be counterproductive. We encourage you to implement the policies you have, rather than try to invent new policies around the features in MAPS. Working with the system owners identified above, you should clearly define the security policies you would like to enforce—this will guide your choice of security configuration.
  • Clearly define your specific security goals: These goals should be a reflection of your security policies. For example, you might have a policy that only Human Resources personnel are allowed to see Social Security Numbers. This would be reflected in the goal, “Restrict access to any tables containing SSNs to only Human Resources staff.”


Step Three: Establish Your Security Framework

Once you have the broader details worked out, it’s time to start building a security framework into your applications. (Below we provide an overview of this step, but please refer to our “Configuration Tips for Improving your Data Security” post for a more detailed walkthrough.)

  • Determine if you intend to create MAPS users or use existing LDAP users: If you have an LDAP server that contains your users, this greatly eases setup and maintenance, as you can simply add the desired LDAP users to MAPS. If you have existing LDAP groups that reflect your organizational structure, you may be able to simply import these groups instead of the individual users (see sidebar on the following page).
  • Determine whether object-level security is sufficient to meet your goals: Object-level security is powerful, flexible, and usually fairly easy to maintain. You may be able to meet most of your security goals by simply ensuring that users or groups are only able to access the appropriate folders and objects.
  • Determine what database permissions DataBlock Designers should have: Since Report Viewers and Writers cannot create new queries, you can generally meet your security goals for these users using only object-level security. DataBlock Designers, however, pose an additional problem as they are able to create new queries and objects. Carefully examine your policies as it relates to these users and configure your database connections to enforce these policies. For example, if a subset of your DataBlock Designers will only be working in the Payroll area, you can make sure that these users connect to the database with an account restricted to only Payroll tables.


Implementing security while still allowing your organization’s users access to the systems they need is not easy. Hopefully by following the recommendations above, you will soon be enjoying the benefits of a more secure reporting environment.

What lessons did you learn, when establishing your institution’s security strategy? Share your wisdom with your peers, by leaving a comment below!

Peter Wilbur

Peter Wilbur is a Professional Services Manager, HES - Professional Services with Evisions and is based out of the company headquarters in Irvine, CA.Peter graduated from Northern Arizona University with a computer science degree in 1984.After working in several industries and with numerous companies, he joined Evisions in 2010 working on the support desk before moving to Professional Services. Peter is a member of the Project Management Institute and a PMP.He enjoys data visualization and is pursuing a certificate in data science.

Latest posts by Peter Wilbur (see all)

Share This