If the security team is right about the access control part depends on what kind of control they do want.
Restricted read
Having any control about what one developer can read is limited both with SVN as with any DVCS. Even when you have a central SVN server typically there is no limitation to read old revisions of paths where you have the permission for. So you could dump the old history revision-by-revision into a local store (hg subversion
, git svn
and lots of other tools work exactly this way). There is nothing magical in SVN which prevents someone from downloading every single revision and distribute these copies.
At the end if you can't restrict the access to the working copies at the user side, you have no read restrictions at all. Period.
Restricted write
This is a different game, since Mercurial allows you to set any name as committer as you want¹. So you need to add some mechanics at the server so that no developer can introduce False-Flag revisions by committing with the name of one fellow developer, and push this revisions to the server. While AFAIK Subversion does set the username by itself on the server, a hg server must somehow be supplied with a hook to check the usernames for all incoming changesets.
¹ There is a way to change the commiter name in Subversion too, but you have to enable the pre-revprop hook on the server to allow this.