Last Updated on November 19, 2022 by maximosecrets

GDPR is all about the privacy of personal data and GDPR comes into force across the European Union and EEA countries on the 25^th May 2018. The potential fines for failure to follow the regulations could amount to 4% of an organizations worldwide annual turnover.

GDPR gives an individual the right to know what personal data is being held, to make corrections if it is wrong and they also have the right to have their personal data erased and to be forgotten. There are other rights too, but basically when looking at the Maximo system we:

• should not hold onto personal data longer than necessary
• should be clear what personal data is being held and what processing takes place on that data – how it is being used
• should be clear who has access to the personal data and why they need to do so
• should highlight personal data that can be seen or transferred to a party that is outside of the European Union and the EEA countries
• should give the right to a person who is a Data Subject to allow their personal data to be used in the manner described in the processes, to allow them to positively opt-in
• should give the right to a Data Subject to opt-out from the processing of their personal data
• should never store sensitive personal data

As implementers of a Maximo system (we are called the Data Processors) on behalf of our clients (Data Controllers) we also have a few duties to perform, we:

• should make our clients aware of the personal data being held
• should make them aware of any potential breaches in data privacy and GDPR
• should train all employees, contractors and third-parties about:
  • GDPR and the rights of data subjects
  • the processes to be followed if access rights to personal data are to be granted to others
  • and the processes to be followed when there is a personal data breach
• should aim for “Privacy by Design” and “Privacy by Default” in how we design or implement a Maximo system.

GDPR will affect new Maximo systems and existing ones. A person’s name is considered Personal Data. With the right to be forgotten GDPR might be interpreted as to require all names to be erased or pseudonymised after they are no longer needed, perhaps at the point a person/labor leaves the employment of the Maximo system owner. However, there may be other regulations requiring information on who performed work on an asset, when this occurred and whether they had the right certifications to perform the work, therefore it is important that the Maximo client as data controller provides the guidance as to how long personal data should be retained within the Maximo system.

Privacy by Design, Privacy by Default

Privacy by Design requires that the data owner and implementer are to consider privacy of personal data at the early stages of design and to reassess privacy throughout the life of the development process. If an existing system is being enhanced then Privacy by Design must still be considered.

Privacy by Default means that individuals should be given a choice as to how much personal data they wish to share with others with the default setting being total privacy. Individuals should opt-in to sharing personal data and they can opt-out again if they choose. An element of privacy by design would give the Data Subject the ability to select (or not) these privacy options at any time.

What would be considered Personal Data in Maximo?

The tables/objects/attributes that could store Personal Data in an out of the box Maximo system are mostly associated with the People, Labor and Users applications, but there are other places as well:

PERSON

The base table behind the People application.

• PERSONID – The unique identifier of the person should not easily identify the person, e.g. WILSONA, SMITHF. It should also not be an employee ID. Better to use an autokey and use the DISPLAYNAME to identify the person. If the employee number needs to be stored for a good reason then use a separate field and control who has access to this through an Attribute Data Restriction.
• DISPLAYNAME – The name of the person. This is personal data and it would be difficult to avoid its use, but it could easily be blanked when no longer required without creating referential integrity issues.
• Primary Phone, Primary Email Address, Primary SMS and Instant Messaging ID, and the tables PHONE, EMAIL, SMS – These could all hold personal data. It is better to not store personal phone numbers and email addresses in Maximo and leave these fields for legitimate business contact data. It would be worth occasionally reviewing the email addresses to look for domains like @gmail, @hotmail, @yahoo, etc and if these are found then email that person to say that to safeguard their personal data, personal email addresses should not be used. That would not be possible with phone numbers but if the person is a Maximo user then adjusting the help text in the Profile – Personal Information to warn the user would be sensible.
• Address fields – This should not hold the person’s home address. A business address would be OK as it is not personal.
• Employee Information – take care what you use these for so that they don’t hold personal data, for example Next of Kin. Business data, like the employee’s manager added to the SUPERVISOR field or the Workflow Delegate would be OK.
• Date of Birth (BIRTHDATE) is personal data. Ask yourself what legitimate reason is there to hold this information in an Asset Management system, perhaps leave that to the HR system. Similarly Hire Date (HIREDATE) and Termination Date (TERMINATIONDATE).
• Next Evaluation (NEXTEVALDATE), Last Evaluation (LASTEVALDATE) might genuinely be needed for safety reasons although it would be better to use the Qualifications aspect of Maximo for this. If it isn’t needed then hide these fields to avoid them being used.
• Procurement Card details – From a security point of view storing card details in a database is not a good idea. Personal card details should not be stored.

PERSONSTATUS

The history table for Person status changes, used by the People application in the Administration module:

• PERSONID – The unique identifier of the Person record is used as the foreign key in PERSONSTATUS and illustrates how the PERSONID is copied around the Maximo database and why then it is preferable not to have it easily identify a person. There are >20 tables with a persistent PERSONID attribute and several hundred places where the PERSONID can be copied; ENTERBY, CHANGEBY, OWNER, LEAD, SUPERVISOR, INSPECTOR, REQUESTBY, etc. In Maximo 7.6 many of these fields have a record hover dialog and if they don’t this is easily added through configuration. The hover dialog displays data from the Person record. If the PERSONID is an auto-keyed value the user will still be able to view the requester, inspector, etc, by hovering over the field.
• MEMO – This is a free format field which could directly or indirectly reference personal data. The action View History in People application should be restricted as this application can typically be viewed by many users.

LABOR

The base table behind the Labor application.

• LABORCODE – The unique identifier of the labor record along with ORGID. Like PERSONID it should not easily identify the person, e.g. WILSONA, SMITHF and it should not be an employee ID. A labor record is linked to a person record and in many places in Maximo the LABORCODE will be shown next to the DISPLAYNAME of the associated person. If it doesn’t then if you are using Maximo 7.6 it would be easy configuration to show a hover dialog that does display the person’s name and other relevant information from the PERSON record. As the field LABORCODE gets used in many places throughout Maximo it is better to not have a meaningful identifier copied to these places especially as in some cases the LABORCODE will be part of the unique key of another table, e.g. LABTRANS.
• Start Location (STARTLOCATION) and End Location (ENDLOCATION) – These two fields store a reference to a Location, that should not be an issue with GDPR. However, if the Location represents a person’s home address and the Geo co-ordinates are held or the address and post code is held then these would be considered personal data under GDPR. If you are using Street Level Routes in Maximo then this could be overcome by using a nearby Service Address or GEO location.

LABORQUAL

• If the LABORCODE easily identifies the person then the qualification records held against this person is likely to be considered personal data and therefore under GDPR it should be accurate and retained only for as long as it is needed.
• The PERSON.DISPLAYNAME identifies the labor record and the qualifications of that person. This tab should be restricted to those who need to have access. The advantage of having an anonymous LABORCODE is if a person leaves then their DISPLAYNAME can be blanked or scrambled and then the qualification records will cease to become personal data, this is not the case if the LABORCODE identifies the person.

USER

The base table behind the Users application in the Security module.

• USERID – The unique identifier of the MAXUSER record. Like PERSONID it should not easily identify the person, e.g. WILSONA, SMITHF and it should not be an employee ID. The USERID record is linked to a person record and this provides the name of the person which the user record belongs to. The USERID is referenced on many other tables in Maximo and often as part of a unique key. There is no reason for the USERID to be meaningful or memorable, as the separate LOGINID is the one used to log-in to Maximo. Good practice and for performance reasons you should periodically purge your tables of inactive users, note, don’t just delete them from the MAXUSER table.
• Use Screen Reader (SCREENREADER) – While this is just a checkbox it is an indicator of visual impairment which would be considered sensitive personal data. If the User application is used by many users then an Application Data Restriction might display this field only when logged in as MAXADMIN.
• DATABASEUSERID – The username for connecting to the database outside of Maximo, for example when using an ODBC connection from Excel. Referenced here because it is likely to be the same as USERID.
• LOGINID – The username used to log in to Maximo. Like PERSONID it should not easily identify the person, e.g. WILSONA, SMITHF and it should not be an employee ID. Like PERSONID, LABORCODE and USERID the LOGINID is used as a key in other Maximo tables.

When Maximo users are no longer needed change the status to INACTIVE. Then occasionally select INACTIVE users and use the action Delete User (it only takes a few seconds), however, the action isn’t available from the List Tab. Note. If you have extended Maximo and used the USERID then be careful that you don’t leave behind redundant data.

MAXUSERSTATUS

The history table for user status changes, used by the Users application in the Security module:

• USERID – The unique identifier of the MAXUSER record is used as the foreign key in MAXUSERSTATUS and illustrates how the USERID is copied around the Maximo database and why then it is preferable not to have it easily identify a person. There are >35 tables with a persistent USERID attribute.
• MEMO – This is a free format field which could directly or indirectly reference personal data. The action View History in Users application might be further restricted unless there are only a few users with access to Users application.

LBSLOCATION

The table that stores the GEO Location of a moving object. For example, Labor, Crew or Asset.

• If you are recording the latitude/longitude of an individual through their company mobile phone or a vehicle which they regularly use and take home then it is likely this information will record where the person lives which is considered Personal Data. You will probably want to delete the records in the LBSLOCATION table for performance reasons. For privacy reasons consider how long you legitimately want to hold on to this data. Do you analyse the data that is more than a week old? Set up a database routine to regularly delete this data when it’s age has reached a threshold.

LOGINTRACKING

This table records when a user log’s in/out of Maximo, it also records all E-Signature attempts.

• It stores the LOGINID and USERID of the person logging in/out or recording the E-Signature. If these fields identify a person then it is considered personal data.
• The NAME field is a copy of the DISPLAYNAME of the Person record associated with the USERID.
• CLIENTADDR is an IP Address of the user logging in (client) and if a business allows remote logins from home then this would be considered personal data under GDPR. CLIENTHOST can also store the same IP Address.
• ADMINUSERID is the USERID of the administrator which is recorded when the administrator logs out another user. This could personally identify that administrator unless USERID is a numeric.

MAXSESSION

This table records the current Maximo user sessions.

• It has fields USERID, DISPLAYNAME, CLIENTADDR and CLIENTHOST which can all contain personal data. Therefore, the Manage Sessions action in the Users application should be controlled to limit the number of users who can see this data. As the session data is purged regularly it will typically have few records unless an audit table has been created for it.

LOGINBLOCK

This table records the IP Addresses that are blocked from accessing Maximo. Typically used for IP Addresses where persistent attacks have been made or servers/users which are no longer permitted to connect to Maximo. Accessed through the action Manage Blocked IP Addresses in Users application.

• CLIENTADDR and CLIENTHOST can both record a person’s IP Address. Under GDPR this will not be an issue unless the REASON field records the name of the person being blocked which is likely. If blocked IP Addresses identify actual people and home addresses then GDPR would require any name to be a pseudonym. Access to the Users application action should also be controlled to limit the number of users who can see this data.

ASSETLOCUSERCUST

• PERSONID – If this field identifies a person, e.g. WILSONA, SMITHF, then take care to understand what the location or asset represents. For example, a location representing a person’s home address would be personal data under GDPR. An Asset recording the vehicle registration of a person’s owned or leased car would be an indirect use of personal data because elsewhere the vehicle registration will more than likely be linked to the individuals home address.
• If a Person is made INACTIVE then the user/custodian records on Locations and Assets that refer to this person should probably be removed, under GDPR the person has the right to be forgotten.

CI

• OWNER – This is the person who is the owner of the configuration item. It is added here to illustrate how the PERSONID can be copied around the Maximo system. If a Person is made INACTIVE then the OWNER ought to be changed to another person.

LOCATIONS

• LOCATION, DESCRIPTION – Take care when using LABOR locationsA physical place where assets exist and where work can be performed. More as it is likely that the LOCATION field references a person and the description their name. A Labor location may be used when recording the transit of items between storerooms or for recording the assets/tools which have been issued to the person represented by the labor record.

ASSET

• Take care when recording vehicle details that are owned or leased to an individual. This can be considered as indirect use of personal data because the vehicle registration number itself can be linked to the individual.

MODAVAIL

• This table is populated using the action Modify Person Availability in the People application. It is needed in order to understand when a person is available for work and used during work scheduling, assignment or dispatching. It may hold the time a person was sick or when they are taking their holidays both of which would be considered personal data. Therefore, care should be taken to restrict access to this data and to delete it when it is no longer needed.

SERVICEADDRESS

• The Service Address has a number of address fields and LATITUDEY and LONGITUDEX attributes. If the Service Address represents a home address of either an employee or customer then this will be considered personal data under GDPR.
• ADDRESSCODE, DESCRIPTION – If the service address represents a home address then it may be that the ADDRESSCODE and DESCRIPTION also contain personal data.

TKSERVICEADDRESS, WOSERVICEADDRESS

• The Service Address can either be copied to the Ticket or Work Order or entered directly if there is no existing Service Address record. It may also be inherited from the Service Address of the Location or Asset. If this data represents a home address then it will be considered as personal data and you will need to consider how to process it and how long it should be retained for.
• SADDRESSCODE, DESCRIPTION – If the ticket or work order service address represents a home address then it may be that the SADDRESSCODE and DESCRIPTION also contain personal data.

TICKET

• REPORTEDBY, AFFECTEDPERSON – These are either the PERSONID or the name of the person who raised the Service Request, Incident or Problem or who had the record raised on their behalf.
• REPORTEDEMAIL, AFFECTEDEMAIL – This is the email address of the person who raised the Service Request, Incident or Problem, or the email address of the person affected, both of which are used in correspondence.
• REPORTEDPHONE, AFFECTEDPHONE – This is the contact phone number of the person who raised the Service Request, Incident of Problem or the phone number of the person affected.

If these fields contain personal data you will need to consider how long this data should be retained for.

WORKORDER

• REPORTEDBY, ONBEHALFOF – These are either the PERSONID or the name of the person who raised the Work Order or who had it raised on their behalf.
• PHONE – This is the contact phone number of the person who raised the Work Order or the contact number of the person who should be contacted.

If these fields contain personal data you will need to consider how long this data should be retained for.

MAXROLE

• VALUE – If the Role type is ‘Email address’ then the VALUE field will be an email address and care should be taken to ensure this is not a personal email address.

COMMTMPLTSENDTO

• SENDTOVALUE – If the Communication Template has recipients of type is EMAIL then the SENDTOVALUE field will be an email address and care should be taken to ensure this is not a personal email address.

COMMLOG

• SENDTO, SENDFROM, REPLYTO – These fields contain an email address. SENDTO may contain multiple email addresses. If email addresses are personal email addresses rather than business ones then you should consider who can view these records and how long they will be retained for.
• SUBJECT, MESSAGE – The corresponding fields in the Communication Template may contain bind fields which are attributes that may contain personal data and whose values will be copied to the SUBJECT and MESSAGE fields and retained in COMMLOG records. Where personal data is being held in Maximo then this will be a good guide as to whether that data may have been copied onto an email and retained in the COMMLOG.

COMPANIES, COMPMASTER

• The assumption here is that a company record is not being used in a personal capacity and is a legitimate company even if that company only employs one person. Company data is generally in the public domain and therefore would fall outside of GDPR. You may need to add an indicator to distinguish companies with several employees from individuals where the information held on the Company record might contain personal data and for these records to then be treated similar to a PERSON record.
• BANKNUM, BANKACCOUNT – These two fields if used should at least be restricted by using an attribute data restriction so that only privileged users can add/update or view this data.
• CONTACT, REMITCONTACT, PHONE, CELLPHONE, FAX – When setting up companies you should perhaps verify that the numbers added to the PHONE, FAX and CELLPHONE are company telephone numbers and not private ones.
• ADDRESS1-5, REMITADDRESS1-5 – The two sets of 5 address fields should represent genuine company addresses and not home addresses. If a home address and not the legal company address then care should be taken to gain permission to store this address and use it through the supply chain processes in Maximo.

COMPCONTACT, COMPCONTACTMSTR

• CONTACT – The name of a contact person at the Company will be considered as personal data under GDPR. This implies that there should be a regular review of contact information held against a company to verify that it remains accurate and to delete it if it is no longer needed.
• EMAIL, CELLPHONE, FAXPHONE, HOMEPHONE, PAGERPHONE, VOICEPHONE – When setting up a company contact you should verify whether any of this information is personal data as opposed to a company provided contact number/email address. HOMEPHONE might be hidden to avoid its use.
• PROCUREMENTCARDNUM – The Procurement Card Number would rarely be used, perhaps if the company has an Internal type, or if the company record is being used as a Customer. This field and the expiration date (PROCCARDEXPIREDATE) should be hidden if they are not used.

REPORTSCHED

• EMAILUSERS – For scheduled report distribution the list of email addresses may contain personal email addresses and this should be avoided.

Note on reports generally. Reports can be written against any part of the Maximo database and it could contain personal data. If a report does contain personal data then it might be more appropriate to not allow report distribution, or to send an email to the recipient with a link to the report output, or to allow users to find scheduled reports from the Report Viewer application.

Concluding Thoughts

The main areas where Personal Data is held in Maximo is found in the Person, Labor and User applications. But as can be seen there are many more places in Maximo where there is the potential to store Personal Data. As the PERSONID, LABORCODE, USERID and LOGINID get copied to other tables often as part of a unique key then you should look to turn as many of these fields into numeric values as you can to reduce the impact of the spread of Personal Data through Maximo.

If you are on Maximo 7.6 you can limit the spread of personal data by utilising the hover-over dialogs to display the name of the person and their contact details. When the Person is no longer needed in the Maximo system then this data can be removed without creating referential integrity issues.

GDPR compliance and the security of Personal Data will become significantly more controllable by taking these two steps. But there is more to GDPR and compliance should be designed into the Maximo system.

The tables and attributes identified above may seem comprehensive but there will be other Personal Data. Every Maximo clients’ implementation is different and not many exist without some degree of configuration. Each Maximo client as Data Controller will need to make their own assessments or ask someone to do it for them. This should take into account all of the Maximo products installed, the configurations made including Audit tables, interfaces both inbound and outbound, reports, attached documents and emails that may contain Personal Data. For example, are reports saved as PDF spreading Personal Data, are photos of people held as attachments, are outbound interfaces copying personal data to other systems, do we receive personal data from an HR system?

While the IBM team have just launched a utility to help blank or scramble Personal Data this will not make the Maximo system GDPR compliant, it will be useful, but there is more to be done including training Maximo users and administrators to be far more aware of Personal Data and how it is processed.