Generally you can segregate duties by using Roles and Access Levels.  You have different types of Administgrators listed in your server document (Full Access Administrator, Administrator, etc, and you can also use roles to show who is allowed to perform certain tasks.  You can have a user with Manager Access, but if you do not allow him USER CREATOR or USER MODIFIER Roles, he will not be ar users in the Address book.

I would suggest that the access for creating / accessing the production dbs be changed to a admin id  that way you would need to change to ID to perform this role and all logs will reflect his new id.   

I swear I posted but don't see it. If this turns out to be a dup, ignore.

The following is a ramble. Sorry, big and complex topic and I like to pontificate. I am the sole admin/dev at my company and we have to deal with these types of issues.

What problem does security want to solve? What's the risk associated with the problem? How many ways can you mitigate the risks? Open a conversation with your security folks and get to the root of their concern.

If there are two of you and you're both devs and admins, then anything you do to try and segregate roles is security theater; both of you can do everything. Unless you staff up or turn one of you into a full time dev and one a full time admin, doing things like playing with roles or switching ID's is just playing 'hide the banana'.

Do you have a good backup system so if the two of you go rogue, the business can recover quickly? Is the backup system managed by someone not you? If it's you, then there is nothing the business can do short of hiring new staff to address that level of risk.

Is there a concern about the two of you adulterating records? Get AuditManager from OpenNTF and set up audit trails. Then again, since you're both gods of the empire, you can muck with the audit system also...

What's the risk if you do split roles? If there's one admin and one dev, what happens when one of you isn't available? Is the loss of business continuity a problem?

Do you have good change control? If so, it should be the source for proof that you're following a process. Security can audit to see if <change> was implemented after change approval (look at time stamps on design elements or docs for instance).

Did either of you bork something and spawn this discussion? How can the problem be prevented?

With small staff wearing multiple hats, the business has to accept some risk associated with 'security'. If you aren't going out of your way to do bad things...perhaps the security staff needs to calm down!

Hope this helps.

I swear I posted but don't see it. If this turns out to be a dup, ignore.

The following is a ramble. Sorry, big and complex topic and I like to pontificate. I am the sole admin/dev at my company and we have to deal with these types of issues.

What problem does security want to solve? What's the risk associated with the problem? How many ways can you mitigate the risks? Open a conversation with your security folks and get to the root of their concern.

If there are two of you and you're both devs and admins, then anything you do to try and segregate roles is security theater; both of you can do everything. Unless you staff up or turn one of you into a full time dev and one a full time admin, doing things like playing with roles or switching ID's is just playing 'hide the banana'.

Do you have a good backup system so if the two of you go rogue, the business can recover quickly? Is the backup system managed by someone not you? If it's you, then there is nothing the business can do short of hiring new staff to address that level of risk.

Is there a concern about the two of you adulterating records? Get AuditManager from OpenNTF and set up audit trails. Then again, since you're both gods of the empire, you can muck with the audit system also...

What's the risk if you do split roles? If there's one admin and one dev, what happens when one of you isn't available? Is the loss of business continuity a problem?

Do you have good change control? If so, it should be the source for proof that you're following a process. Security can audit to see if <change> was implemented after change approval (look at time stamps on design elements or docs for instance).

Did either of you bork something and spawn this discussion? How can the problem be prevented?

With small staff wearing multiple hats, the business has to accept some risk associated with 'security'. If you aren't going out of your way to do bad things...perhaps the security staff needs to calm down!

Hope this helps.

Security audit finding usually have a recommendation or requirement part. Some can be handled via additional ID or policies. Some required involvement of additional parties within your company. Some might require you to implement some sort logging / audit tools. Some might require additional manpower or shifting of roles.

The topic is just to wide for us to be able to give you any concise answer.

It simply goes without saying that giving the same person admin, dev, and support roles, merges those roles into one person. This isn't abnormal, either. DevOps.

Whoever thought that someone could actually implement stovepiped security when all this is concentrated in one person, that is kind of an odd fellow Frankly, whatever you do with one person, it isn't security you're accomplishing.

That said, I would suspect your security people are starting to act on behalf of system-integrity. Those are two different things: one deals with a determined insider. The other deals with inadvertent destruction due to unwise choices.

Integrity makes certain actions hard; security makes them impossible.

System integrity can be assured through proper use of policies. You can accomplish that by allocating admin IDs; by prohibiting developer IDs from operating on production systems; by making good backups of your systems; and then for developers, making good backups of existing designs in dev & prod.

BTW, this last can be accomplished from within Notes. I write a small app where I go to read-off a list of databases to backup, check modification dates vs. the last backup, and make new design backups, including config & profile docs. It's not hard, and it's a relief to find that you have a design backup available when you need it.