...because all commits (diffs) and new files being added to the repository are checked and signed off by the repository 'owner'...
It's important to remember that Git does not store diffs of any kind. Every commit contains a complete set of all the files for that commit. Commands such as git diff and git log -p generate diffs on the fly from the complete files in the commits they are comparing.
...and any new files would show as new to the local version when a status or pull is made.
New files will not show up when you run git status or git pull (or git fetch followed by git rebase, which is the equivalent of git pull). So if you're relying on just that, you won't get any indications that new files have been added; they will just quietly appear in your working copy.
For any commit with only one parent, you can use git log --stat to see the entire list of new and changed files, but it doesn't distinguish between the two, and newly introduced files (or files where it would be suspicious if they are changed) can easily get lost in commits that affect a lot of files. For single-parent commits git log --patch will distinguish new files from changed ones, but there it's even easier to miss new files in a commit that affects a lot of files, or even just a lot of lines in a few files.
Unfortunately, this all breaks down if you have commits with more than one parent, i.e. merge commits, in your repo. git log --patch and even git diff do some suppression of information that people don't normally want to see about a merge, and this includes files newly introduced in merge commits (or at least did so in the past--I myself avoid merge commits now). In particular, I've seen it completely suppressing information about new files added in the "merge" commit itself (i.e., existing in neither parent commit, which doesn't normally happen when doing a merge); in the most egregious example most of the files in the repo (hundreds of them) were somehow added in a merge commit and it took me ages to figure out where they came from. (They definitely did not show up in git log --stat.)
If you are interested in reliably being able to review exactly what is being changed in your repo (including new file additions), my suggestion is that you avoid merge commits or anything else that can result in a commit having more than one parent. Then you can use git log --stat and git log --patch and know you're looking at the exact and complete changes introduced by that commit.