There is no compliance reason why OP couldn't have read access to look at the source.
If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use.
Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.
(Said having worked at both companies with global read visibility & access scoped to team only)
> There is no compliance reason why OP couldn't have read access to look at the source.
Companies can have whatever compliance terms they like, whether they map to ISO27001 controls or not.
> Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.
Or they believe it's a reasonable control. Let's imagine this is a company working on self driving cars. Your source code is probably something you want to protect very carefully.
> * There is no compliance reason why OP couldn't have read access to look at the source.*
At a guess, I would say you have never worked with DRM integration. Getting access even to the binary SDK's can take months, and if you ever need the special license to work with the thing on source code level, prepare for a delay of several quarters.
Long time ago, Nokia was integrating Microsoft's DRM. I got to witness first hand the red tape needed to allow a new person to even see the source code the team worked with. And this was thanks to requirement MS imposes on their licensees.
The other code I know of that was heavily siloed were Nokia's DSP codecs. Pretty sure there were other corners with similarly absurd external restrictions but at least I was never exposed to them.
My closest experience was working with SDK of CCTV system. Which, after six months of waiting for legal, ended up being the ugliest and most obtuse codebase I've ever seen.
Thankfully, it was an optional side project at work, so I was able to step away and make more progress elsewhere.
But it also substantially reinforced my opinion that... if you need to keep a codebase secret... it's probably not a good thing.
And yes, I realize it is sadly endemic in the embedded world, for reasons both good (firmware secrets) and bad (artificial moats and controlling integration and compatibility).
If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use.
Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.
(Said having worked at both companies with global read visibility & access scoped to team only)