This might be compounding the problem by adding an extra item to the list, but how about a database? You have a set of entities (databases, applications, user groups, servers and other network resources) with obvious relationships (user group A relies on application B, application B refers to database C directly, application C exports data from database D to file E, application B imports file E into database C, ...). You might sub-divide the data in the databases too (if both database C and D haver personnel data and that is what is transferred in file E, perhaps that data subset should be an entity in its own right).

For each entity you probably have a fairly well defined set of properties you care about to: databases will have a type (SQL Server, Access, ...), a core location (server+instance).

Of course there is a lot of information that you will want to include in such an audit (where does a database get backed up to? who has what sort of access to a given server/instance/db? where is documentation held and who is responsible for maintaining it?) so designing this database could become a project in its own right so might be overkill unless there is an off-the-shelf solution you can beat into the shape you want.

This might be compounding the problem by adding an extra item to the list, but how about a database? You have a set of entities (databases, applications, user groups, servers and other network resources) with obvious relationships (user group A relies on application B, application B refers to database C directly, application C exports data from database D to file E, application B imports file E into database C, ...). You might sub-divide the data in the databases too (if both database C and D have personnel data and that is what is transferred in file E, perhaps that data subset should be an entity in its own right).

For each entity you probably have a fairly well defined set of properties you care about to: databases will have a type (SQL Server, Access, ...), a core location (server+instance), servers have hardware specifications, physical ages, relationships with other servers/resources (for backups and such if nothing else).

Of course there is a lot of information that you will want to include in such an audit (where does a database get backed up to? who has what sort of access to a given server/instance/db? where is documentation held and who is responsible for maintaining it?) so designing this database could become a project in its own right so might be overkill unless there is an off-the-shelf solution you can beat into the shape you want.